I don't necessarily agree ... parallel streams can handle immense amounts of data if they're processing a suitable data set. The problem that's being described

I don't necessarily agree ... parallel streams can handle immense amounts of data if they're processing a suitable data set. The problem that's being described was prevalent when threads were being created manually too. Like anything else, the tool needs to be matched to the job. We processed about 32E9 pieces of telemetry per day ... our parallel threads were normalizing and aggregating that data as well as preparing it for storage. If you have too many threads waiting, you've got too many threads. I did a significant amount of testing using threads (on a project I can't share) and found that generically, you should have n + 1 threads when you have n processor cores. If your processor I/O bandwidth is limited, you may find better performance with less processors. If you're creating something like a tick-store (Michael Stonebraker - newest Turing award winner), you'll need to tune the rest of the system to feed the processors data at the maximum rate too. We were using E15K (and another bigger machine I can't remember) and used processor affinity to make sure all but 3 of the processors were dedicated to parallel threads. The thread count was the number of dedicated processors plus one. Having too many threads leads to context churn ... think about what you're trying to accomplish and design the system appropriately. And of course, some problems need other solutions.