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 both MultithreadedExecutor and Query::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 and Query::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.