Open shepmaster opened 8 months ago
Indeed, I have faced a similar and more extended version of this problem.
I came up with the following workaround for my particular case:
fn setup(rt: &runtime::Runtime) -> u64 {
rt.block_on(async {
// do async stuff
tokio::time::sleep(Duration::from_millis(100)).await;
1
})
}
async fn test() -> u64 {
1
}
pub fn criterion_benchmark(c: &mut Criterion) {
let rt = runtime::Builder::new_multi_thread()
.enable_all()
.build()
.unwrap();
let setup = setup(&rt);
c.bench_function("demo", |b| {
b.to_async(&rt)
.iter_batched(|| setup.clone(), |_| async {}, BatchSize::SmallInput);
});
}
Right now, the setup closures return a synchronous value, not a future, disallowing setup from being async.
Additionally,
iter_batched
wraps the call tosetup
in ablock_on
call:https://github.com/bheisler/criterion.rs/blob/b913e232edd98780961ecfbae836ec77ede49259/src/bencher.rs#L622-L631
This means that you can't use
block_on
in the closure yourself as that would create a nested runtime:Our current workaround is to use
iter_custom
instead.