libtest bench async/await support

[GopherJ]

can libtest offer b.iter_async to make it possible to run async functions?

b.iter_async(async {
  // async call
})

because it seems if we are using aynsc_std::task::block_on or other runtime, that may influence the result

[jonas-schievink]

Which executor would iter_async use? Why is it better than the one in async-std?

[Mark-Simulacrum]

I think this is major enough that we would need an RFC for it; it essentially means offering some executor in std/test. I suspect, though could also be wrong, that in particular for benchmarking that could be a bad idea (since you'd be benchmarking at least partially your executor, and std's is unlikely to be best-in-class for your specific problem).

[GopherJ]

@jonas-schievink I believe any executor can be used, I just don't want to create async runtime in bench iterator, because it will influence the result.

Instead of creating an async runtime in every bench iterator, why not create just one runtime and spawn tasks on it?

[GopherJ]

Or maybe bencher should be sperated into a crate so that we can use different runtime.

I found one but it's not maintained

[GopherJ]

I think this is major enough that we would need an RFC for it; it essentially means offering some executor in std/test. I suspect, though could also be wrong, that in particular for benchmarking that could be a bad idea (since you'd be benchmarking at least partially your executor, and std's is unlikely to be best-in-class for your specific problem).

I think we can also let b.iter_async accepts an executor, no need to have an executor in rust std side

b.iter_async_with(tokio::runtime::Runtime::new().unwrap(), async {
  // async call
})

Currently it's a pain to benchmark async code....

[Stargateur]

also the [bench] attribute doesn't support async function.

[k06a]

@Stargateur any progress on this?