Asynchronous profiling

[rivertam]

Hey, sorry if this is already addressed in another issue or worse yet the documentation, but I would love a way to do really custom profiling where I profile between two specific points in not-necessarily-synchronous code. For example,

// I guess I'll have to assume `c` is in an `Arc` or something

events.on("I haven't actually written an event emitter this is just an example", |_data| {
    c.finish("AsyncBench");
});

c.begin("AsyncBench");
events.emit("I haven't actually written an event emitter this is just an example", 5);

Is something like this supported, or will it ever be?

[bheisler]

Hey, thanks for trying Criterion.rs, and thanks for the suggestion!

This definitely doesn't exist now. Will it ever? Hard to say, really. I'm planning to open things up more for custom measurements in 0.3.0, so it might be possible to implement something like this in a third-party crate eventually. It doesn't seem like it would be a common-enough use case to belong inside Criterion.rs itself. On the other hand, whenever async/await support lands, it might be more useful to be able to benchmark systems involving asynchronous tasks.

I'll leave this open as a wish-list item for now and see what the future brings.

[spacemeowx2]

async fn is stable now. any new plans?

[bheisler]

async fn is not really relevant here; the request was to be able to insert markers at arbitrary points in the code and benchmark the time between them.

If you want to benchmark async functions, I would recommend running them to completion using futures::executor::block_on inside the benchmark as long as they don't require any network traffic to external systems (and if they do, it probably doesn't make sense to benchmark them anyway).

[rivertam]

@bheisler That's a good point. You could convert my earlier example into valid code by using a one-shot channel future and then blocking on it.

[GopherJ]

@bheisler I doubt if futures::executor::block_on can get the real numbers because block_on is a little be heavy and maybe we should reuse the same async runtime?

See also: #363 #403