rt: add a runtime builder option to turn off time-based metrics

[fMeow]

Is your feature request related to a problem? Please describe.
No.

Describe the solution you'd like

Add a runtime builder option to turn off time-based metrics, and enable it by default to keep the same behavior as of now.

Describe alternatives you've considered
Feature gate to opt out of time based metrics? I think it too far though.

Additional context
I have encouter a noticeable performance regression and a flamegraph shows that the time based operation took up too much time. My scenario involves a lot of spawned tiny task and heavily relies on yield_now(). Each task might run for hundreds of microseconds. And the timed-based metrics called Instant::now and Instant::elapsed for each task already takes up dozens of microseconds.

Here is a mininal MVP. Notice that only calling yield_now already cause performance regression. I tested elapsed time between tokio 1.44.1 and 1.47.1, and the impact of time based metrics is quite obvious.

fn main() {
    let rt = tokio::runtime::Builder::new_current_thread()
        .build()
        .unwrap();
    let now = std::time::Instant::now();
    rt.block_on(async move {
        for _ in 0..100_000_000 {
            tokio::task::yield_now().await;
        }
    });
    println!("Elapsed: {:?}", now.elapsed());
}
// tokio 1.44.1 Elapsed: 4.043231438s
// tokio 1.47.1 Elapsed: 11.043426378s

And the flamegraph on the tokio 1.47.1 version shows that time based operation is quite heavy, with Timespec::now (the underlying syscall from Instant::now) and Instant::elapsed already took up 63% of the total flame. I think the gained observerbility is not worthy for a performance regression up to around 20% in my real world scrienario. And would like to find a way to turn off time based metrics.

[conradludgate]

At least for some more data points, in my production service running tokio 1.47.1, I measure a 0.09% overhead from the poll time metrics (3,454 samples on Instant::elasped, 3,840,490 samples on Harness::poll).

A yield_now().await loop is clearly a very extreme edge case

[fMeow]

The given example is indeed a extreme and non-realistic use case. The overhead in my production code is around 10%.

I generate a flamegraph with my production code, and the Timespec::now and Instant::elapsed took around 8%-10% overhead with tokio 1.47.1. It shows 78,271,546,045 samples on Timespec::now and 6,471,314,856 samples on Instant::elapsed, with 945,981,506,773 total samples. I also rerun the same code base with only change that lock tokio version by tokio = "=1.44.1" in Cargo.toml, and the Timespec::now and Instant::elasped did not appear in flamegraph.