Please include async-channel in benchmarks

[joshtriplett]

Please consider adding the async-channel crate to the benchmarks. It's part of the async-std and smol stacks, and I would like to see how it compares.

[Restioson]

Currently, there are no benchmarks which are asynchronous, as we're not really sure how async benches should be measured. Do you have any suggestions to do so? The other option would be to wrap each call to async-channel in block_on, but this has overhead.

[joshtriplett]

@Restioson I'd suggest two benchmarks: Thread-per-CPU and Single-threaded. (There are other possible configurations, but those will be the most common.)

The actual benchmarks should be all the same things you currently benchmark, with the producers and consumers sitting in separate tasks, and the only question is whether those tasks run concurrently or not.

You already have flume synchronous benchmarks; you could add "flume async thread-per-CPU", "flume async single-threaded", "async-channel thread-per-CPU", and "async-channel single-threaded".

(That'll also allow comparing flume sync and async performance.)

[Restioson]

How should the performance of the tasks be measured? We could block_on them and throw them in a criterion b.iter but this could also just be measuring general futures overhead

[joshtriplett]

You could call .detach() on them and use them exactly like you're currently using threads, just substituting send_async().await and recv_async().await in place of the send and recv calls, and then see how long the overall operation takes to complete just as the current benchmarks do.

For thread-per-CPU, something like smol::spawn with SMOL_THREADS=$(nproc) would work. For the single-threaded case, you could create a LocalExecutor and run tasks on that. (Don't just run a multi-threaded executor with one thread, run a specifically single-threaded executor.)