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
{{ message }}
Repository navigation
Add slim dedicated implementation of Parallel loop APIs #57580
#57283 made Parallel.Invoke/For/ForEach work in WASM but there's a lot of cruft attached, the ideal long term solution is a simple custom implementation that doesn't pull in unnecessary dependencies. This probably pairs well with a wasm implementation of PLINQ.
@kg, is this still something we might do or should we close it?
I don't have the data I would need to answer this. I think it's a question of whether the normal parallel APIs have too much overhead (in both time and code size) on the current implementation. Do we have benchmarks for them that already run?
I would lean towards not doing anything unless we hear feedback from users that it's necessary, especially since we will eventually have actual threading available and the slim version will not be useful in that scenario. These APIs have a lot of overhead in their design to begin with.
We would have the ability to conditionally ship either the slim or non slim version depending on whether we have threads, at least. So if we build a slim implementation it won't make the threaded scenario worse.
Activity
stephentoub commentedon Jan 21, 2023
@kg, is this still something we might do or should we close it?
kg commentedon Jan 21, 2023
I don't have the data I would need to answer this. I think it's a question of whether the normal parallel APIs have too much overhead (in both time and code size) on the current implementation. Do we have benchmarks for them that already run?
stephentoub commentedon Jan 26, 2023
I don't see any benchmarks for these in dotnet/performance.
kg commentedon Jan 26, 2023
I would lean towards not doing anything unless we hear feedback from users that it's necessary, especially since we will eventually have actual threading available and the slim version will not be useful in that scenario. These APIs have a lot of overhead in their design to begin with.
We would have the ability to conditionally ship either the slim or non slim version depending on whether we have threads, at least. So if we build a slim implementation it won't make the threaded scenario worse.
stephentoub commentedon Jan 26, 2023
SGTM.