TaskFactory.StartNew versus ThreadPool.QueueUserWorkItem

Question

Apparently the TaskFactory.StartNew method in .NET 4.0 is intended as a replacement for ThreadPool.QueueUserWorkItem (according to this post, anyway). My question is simple: does anyone know why?

Does TaskFactory.StartNew have better performance? Does it use less memory? Or is it mainly for the additional functionality provided by the Task class? In the latter case, does StartNew possibly have worse performance than QueueUserWorkItem?

It seems to me that StartNew would actually potentially use more memory than QueueUserWorkItem, since it returns a Task object with every call and I would expect that to result in more memory allocation.

In any case, I'm interested to know which is more appropriate for a high-performance scenario.

Answer 1

Just from the looks of things, the Task classes were designed to work with the new parallel features in .Net 4. It also looks like you can use Action or Action<T> directly when starting/creating a task. This is all 100% conjecture, though, based on poking around the docs :).

Answer 2

Performance is a ... depends. If you are doing a lot of parallel tasks, then .net 4 tasks will perform better, plus give you more fine grained control (more robust cancellation, ability to wait on multiple tasks simultaneously, ability to create parent/child task relationships, Ability to specify LongRunning, etc.. etc.. etc..)

Additionally, the ability to specify your own TaskScheduler means you can customize it for your needs. The built-in task scheduler is far more multi-core aware than the old ThreadPool.

As for using more memory. Every thread uses a minimum of 1MB of memory, the tiny amount used to store a task object is inconsequential. I really would think that's the last of your worries.

Answer 3

TaskFactory.StartNew is more appropriate for a high performance scenario.

You gain a productivity benefit by the set of classes in System.Threading.Tasks and the care that went into their design + integration with the parallel loops and options.

You'll also gain a performance benefit because System.Threading.Tasks are built on top of work stealing in the thread pool which is better for locality (when it matters).

-Rick