Mar 25, 2014 07:53 PM|_Manvel_|LINK
Let's begin with the title of your question
Task or in that matter using thread won't be giving you any performance gain. They are all about "doing some stuff" in parallel. So for example if you have some "stuff to do" that can actually be divided into smaller pieces, and processed in parallel,
then you might improve performance. In your case, your task is to generate a report, and it is a simple method call, so from what I see there is nothing that can be divided to sub-tasks and processed in parallel. So actually code that you have won't be giving
you any performance improvements.
Your question is little bit confusing, in the title you're reffering to Task vs Thread, than in the question your asking whether you should switch to ThreadPool. If you create a Thread, you'll be creating actual OS-level thread with it's own resources,
which is costly, as it will have it's own memory for it's stack, additional CPU cycles because of processor's context-switches. This is something I would highly recommend you to stay away from.
If we're talking about Queueing some user work on ThreadPool or using Task, mostly it will be the same (as you're stating in the post, you couldn't see any difference between Task and using ThreadPool). The reason is that TPL's default Scheduler will use
ThreadPool's threads to perform tasks on them, and since you're using the default one, there is no difference in regards of resources being used.
Now IIS uses Thread Pool's threads to serve requests, so if you fire too much of tasks (or queue work on ThreadPool), you will actually consume some of those threads that are dedicated to serve the requests. Keep in mind also, that IIS actually restarts
AppDomain periodically, so running a task is not safe in terms that, while task will run, IIS recycling may occur, and your task will be terminated without finishing.
So putting this all together, your code is not improving anything, but actually consumes some threads from the threadpool, and has potential danger, that it won't be finished (in case of IIS recycling).
Going further, you said that users don't have to wait until report is generated, they will be notified when it's done, and they will check the report later, on a different page, so it's hard to understand what kind of performance improvement you're seeking
Remember, in general, async calls don't give you performance gain, they give you scalability gain - by processing long-running tasks on different thread (other than Thread Pool thread), which let's current thread to get back to Thread Pool to serve other
give any performance improvement, it will simply keep page alive, and user can continue working on the page).