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