CODEWITHSUNDEEP
c#multithreading
Nick
Nick

Reputation: 10499

Why so much difference in performance between Thread and Task?

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();
    timer.Start();

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

    timer.Stop();

    Console.WriteLine(timer.Elapsed.TotalSeconds);
    Console.ReadLine();
}

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?

Upvotes: 31

Views: 34378

Answers (6)

Dennis Gorelik
Dennis Gorelik

Reputation: 1316

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.

http://dennisgorelik.livejournal.com/125269.html?thread=2238805#t2238805

Upvotes: 1

sll
sll

Reputation: 62484

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! :)

Upvotes: 0

Richard Schneider
Richard Schneider

Reputation: 35477

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!

Upvotes: 4

Trevor Pilley
Trevor Pilley

Reputation: 16393

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.

Upvotes: 0

user7116
user7116

Reputation: 64068

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.

Upvotes: 4

Reed Copsey
Reed Copsey

Reputation: 564353

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.

Upvotes: 43

Related Questions