Home » c# » Why so much difference in performance between Thread and Task?

Why so much difference in performance between Thread and Task?

Posted by: admin February 22, 2018 Leave a comment


Windows 7, Intel CORE i3, 64 bit, RAM 4Gb, 2.27 GHz
.NET Framework 4.0

I have the following code:

static void Main(string[] args)
    var timer = new Stopwatch();

    for (int i = 0; i < 0xFFF; ++i)
        // I use one of the following line at time
        Task.Factory.StartNew(() => { });
        new Thread(() => { }).Start();



If I use Task the output is always less then 0.01 seconds, but if I use Thread the output is always greater than 40 seconds!
How is it possible? Why so much difference?


The two are not the same.

When you use Task.Factory.StartNew, you’re scheduling a task to run on the ThreadPool. When you make a new Thread, you’re having to create and start a new thread.

In the first case, the threads are already created and reused. This causes the overhead of scheduling the tasks to be far lower, as the threads don’t have to be created each iteration.

Note that the behavior is not the same, however. When creating a separate thread, each task is getting it’s own thread. They will all get started right away. When using Task.Factory.StartNew, they’re put into the scheduler to run on the ThreadPool, which will (potentially) limit the number of concurrent threads started. This is usually a good thing, as it prevents overthreading from occurring.


Every time you start a Task it goes into a pool to be served by a number of threads, many of which may be pre-created. There is an M:N ratio of tasks to threads in the pool.

Every time you start a Thread it creates a new thread and all of the overhead associated with thread creation. Since you are explicitly creating a thread, there is a 1:1 ratio of threads.

The closer the ratio of tasks to threads reaches 1, the “slower” task startup it will take. In reality, the ThreadPool ensures the ratio stays much higher than 1.


You have an issue with your test, in that you don’t wait for each Thread/Task to finish.

Task uses a queue, so its much faster to create a Task than a Thread.

I’ll bet that even if you waited for Tasks/Threads to finish, that using a Task is faster. The overhead of creating and then destroying a Thread is high. That’s why the Task.Factory was created!


Calling Task.Factory.StartNew doesn’t necessarily create a new thread, they are managed by the TaskScheduler based upon how many cores etc the machine has that is running the code.

If you schedule (by calling Task.Factory.StartNew) more tasks than can be concurrently run, they will be queued and run as more resources become available.


Task.Factory.StartNew() does not start a task immediately it just schedules it so a TaskScheduled would be able starting it a bit later (depends on number of available threads/tasks).

MSDN saying that after Thread.Start() operating system can schedule it for execution, interactions with OS is much slower than with .NET Framework’s TaskScheduler but not in such degree.

And back to your example, 0xFFF == 4095, so you are scheduling 4095 threads and this takes 40 seconds. 102 threads in a second is a pretty good timing! 🙂


Creating new threads is slow, but not that slow.
Nick reported ~10ms/thread.
Most likely it happened under Visual Studio debugger.
I am getting ~3.9ms per new thread under Visual Studio debugger.
I am getting ~0.15ms per new thread without debugger.