Description
We use threading in multiple places, and use System.Collection.Concurrent blocking collections, in particular queues, to have "ordered" work among gangs of worker threads. When debugging this specific .NET structure has a high cost, given our usage pattern. PR #2595 introduces a new mechanism to use in place of a blocking queue. This shows substantial speedups during debugging during our usage of it.
That's great for that PR, but that was focused on the text loader specifically, since that shows up in our initial examples. It may be that the debugging experience is problematic elsewhere in situations that are important but not written for our documentation writer. Perhaps we can apply the same innovation to other scenarios. (It may be as simple as a simple drop and replace, in which case 90% of the work would be writing appropriate benchmarks.)
Targeted scenarios that may benefit include the splitter/consolidator logic for concurrent featurization pipelines, cache data view, and the binary loader, since their internal workflow follows this pattern of gangs of thread workers producing/consuming ordered batches of data.
Probably something to think about post v1.