You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We should anticipate that when we put out the futures-concurrency RFC that members of the community may ask about which benefits e.g. join or merge provide over abstractions like task::spawn or select! {}. There are several benefits, including integration with debuggers, ease of use, documentation, structured concurrency, and overall correctness. But also, and this is relevant to the recent work we've been doing: performance!
We should author a benchmark comparing e.g. tokio::spawn and tokio::spawn_local against {tuple,array,vec}::join. We may want to implement #82 for futures as part of this, so we can control the number of wakes and don't exclusively perform synchronous work. But it'll be interesting to see the performance delta between the two.
The text was updated successfully, but these errors were encountered:
yoshuawuyts
changed the title
Add a benchmark comparing task spawning vs in-line join
Add a benchmark comparing task spawning vs in-line joining
Nov 16, 2022
We should anticipate that when we put out the futures-concurrency RFC that members of the community may ask about which benefits e.g.
join
ormerge
provide over abstractions liketask::spawn
orselect! {}
. There are several benefits, including integration with debuggers, ease of use, documentation, structured concurrency, and overall correctness. But also, and this is relevant to the recent work we've been doing: performance!We should author a benchmark comparing e.g.
tokio::spawn
andtokio::spawn_local
against{tuple,array,vec}::join
. We may want to implement #82 for futures as part of this, so we can control the number of wakes and don't exclusively perform synchronous work. But it'll be interesting to see the performance delta between the two.The text was updated successfully, but these errors were encountered: