How many tasks are too many?

Question

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

1. running actively, meaning they're sending their request to the web service and are waiting for a response or processing the response

2. 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?

Answer 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 such 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:
.NET 4.0 - Performance of Task Parallel Library (TPL), by Daniel Palme

This is another interesting article on the subject:
CLR Inside Out: Using concurrency for scalability, by Joe Duffy