Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Benchmark and configurable pool #190

Open
tisonkun opened this issue May 26, 2024 · 4 comments
Open

Benchmark and configurable pool #190

tisonkun opened this issue May 26, 2024 · 4 comments
Labels
enhancement New feature or request

Comments

@tisonkun
Copy link

Hi @notgull and all,

I like the design of async-io that it doesn't bind to any async runtime but has its own reactor to schedule IO tasks.

So I'm considering using async-io to replace some usage of tokio's io/net structs. But here are two concerns before the decision and your feedback would be valuable :D

  1. Is there any benchmark shows the comparison to tokio? I wonder if there is significant regressions, tie, or outperformance.
  2. Currently, async-io uses a global shared thread pool to schedule all the tasks. I wonder if it can be configurable. That said, most of the time a globally shared runtime is enough, but I may let the runtime dedicated to my code, not shared among all the crates use async-io.
@notgull
Copy link
Member

notgull commented May 26, 2024

  1. Is there any benchmark shows the comparison to tokio? I wonder if there is significant regressions, tie, or outperformance.

None yet. It depends on the workload. The main difference between smol and tokio is that smol uses oneshot polling and tokio uses edge polling. As a general rule of thumb short-lived tasks will complete faster on one shot polling, but longer-lived tasks will complete faster with edge polling.

  1. Currently, async-io uses a global shared thread pool to schedule all the tasks. I wonder if it can be configurable. That said, most of the time a globally shared runtime is enough, but I may let the runtime dedicated to my code, not shared among all the crates use async-io.

async-io doesn't do this, you may be thinking of [async-global-executor], which is largely async-std specific. In smol you typically create your own Executor and pass it to your code.

@tisonkun
Copy link
Author

async-io doesn't do this, you may be thinking of [async-global-executor], which is largely async-std specific. In smol you typically create your own Executor and pass it to your code.

My intention may be about this global thread pool:

        thread::Builder::new()
            .name("async-io".to_string())
            .spawn(move || main_loop(parker))
            .expect("cannot spawn async-io thread");

This pool is shared among all the crates in the final binary. I wonder if making this pool associated to the reactor, and allowing users to pass their own reactor instance instead of always use the global Reactor::get a possible evolving direction.

async-executor works well and is one of the alternative scheduler I'd replace tokio in the context of this issue. But it's unrelated to this dedicated thread pool topic.

@notgull
Copy link
Member

notgull commented May 27, 2024

My apologies, I was confused. This isn't a thread pool; it's a single thread that acts as a fallback for when no other thread is running async_io::block_on.

I've considered adding configurable reactors in the past, but I've avoided implementing it because it adds a lot of complexity for very little real-life benefit. The reactor isn't very opinionated anyways, so there shouldn't be an issue with sharing it among multiple different packages.

@notgull notgull added the enhancement New feature or request label May 27, 2024
@tisonkun
Copy link
Author

@notgull Feedback received. I understand the situation here now.

You can keep it open for further improvement if anyone would spend time to allow dedicated Reactors.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Development

No branches or pull requests

2 participants