Switch to using static async executors #11849
Labels
A-Tasks
Tools for parallel and async work
C-Performance
A change motivated by improving speed, memory usage or compile times
S-Blocked
This cannot move forward until something else changes
S-Needs-Benchmarking
This set of changes needs performance benchmarking to double-check that they help
What problem does this solve or what need does it fill?
An investigation in smol-rs/async-executor#91 found that the lock on
async_executor
's state can have significant overhead when spawning new tasks in large batches, something that bothMultithreadedExecutor
andQuery::par_iter
heavily rely on.What solution would you like?
Use the APIs implemented in smol-rs/async-executor#92 to batch spawn tasks in both the
MultithreadedExecutor
andQuery::par_iter
.Alternatively, smol-rs/async-executor#112 eliminates the cost of the lock entirely, but switching to use a static executor will require additional user-facing API changes.
What alternative(s) have you considered?
Leaving it as is.
Additional context
This will likely require shuffling how we spawn tasks in the mulithreaded executor so that we do not end up holding the async_executor lock for longer than necessary.
Query::par_iter
doesn't have these issues and it should be fairly trivial to integrate.In their current state, we may need have a type implement
Extend<Task<T>>
that just takes receives and detaches the spawned tasks to avoid roping the allocator into the loop.The text was updated successfully, but these errors were encountered: