问题
I'm currently working on an application that relies on many different web services to get data. Since I want to modularize each service and have a bit of dependency in there (service1 must run before service 2 and 3 etc), I'm running each service in its own task.
The tasks themselves are either
running actively, meaning they're sending their request to the web service and are waiting for a response or processing the response
waiting (via monitor and timeout) - once a task finishes all waiting tasks wake up and check if their dependencies have finished
Now, the system is running with what I would call good performance (especially since the performance is rather negligible) - however, the application generates quite a number of tasks.
So, to my question: are ~200 tasks in this scenario too many? Do they generate that much overhead so that a basically non-threaded approach would be better?
回答1:
The general answer is "Measure, Measure, Measure" :) if you're not experiencing any problems with performance, you shouldn't start optimizing.
I'd say 200 tasks are fine though. The beauty of tasks compared to threads is their low overhead compared to "real" threads and even the thread pool. The TaskScheduler is making sure all the hardware threads are utilized as much as possible with the least amount of thread switching. it does this by various tricks suck as running child tasks serially, stealing work from queues on other threads and so on.
You can also give the TaskScheduler some hints about what a specific task is going to do via the TaskCreationOptions
If you want some numbers, check out this post, as you can see, Tpl is pretty cheap in terms of overhead
http://www.palmmedia.de/Blog/2010/1/19/net-40-performance-of-task-parallel-library-tpl
This is another interesting article on the subject
http://msdn.microsoft.com/en-us/magazine/cc163552.aspx
来源：https://stackoverflow.com/questions/19348145/how-many-tasks-are-too-many