+4  A: 

"I get the feeling this design element has an impact on performance."

Don't guess, get a profiler out and measure what's going on. Gather some empirical stats about where time is spent in the application and then you can take a view on where the pinch points are.

If the time spent creating threads is your biggest headache then moving to a threadpool may be the right answer, but you won't know without some forensic analysis.

From the small snippet you've posted it looks like the 14 threads are reasonably long-lived, doing multiple things over their lifetime so I suspect that this is not the problem actually, but there isn't enough info in your post to make a definitive call on this.

Paolo
So you're suggesting that even though there are 14 threads running constantly, the actual code inside the classes may just be terrible and thus causing the application to run slowly?
Goober
It's entirely possible. Note if they all have a Thread.Sleep(5000) they aren't running constantly either.
Paolo
A: 

if your threads are all doing work and you have more threads active than processors then you are going to be spending time context switching.

If you have a dual core processor dont expect to get great performance with more than 4 active working threads.

So starting off 14 threads that are all doing work is a bad idea unless you have a processor that can manage this. Physical processor architecture and feature set has a big impacrt on this. My point is that a threadpool will help manage the context switching but starting 14 busy threads at once is always gonna kill performance ... you will probably get faster performance from simply excuting the threads sequentially. Obviously that is a big statement and so is probably not trus, but you get the gist.

Hence the use of a thread pool along with a profiler to figure out the optimum number of threads to make available to the thread pool.

In most situations when people are usign a thread pool a lot of the threads are doing nothing most of the time, or a thread is sleeping/blocking whilst some slow operation or external dependancy awaits a response.

consider using an asynch pattern so that you can get info about progress out of your threads.

On a dual core processor i would be hesitant abou tusing more than 3 threads if they are all working 100% of the time

John Nicholas
- I've added some information about the server to the start of the question.
Goober
a rough rule of thumb i have found is that each processor can cope with about 2 threads ... but this is specific to core duo architecture that i use at home where I ahve tested. You really need to do the experiements ... there is nothing better than empirical evidence - the threadpool was pretty much designed for this.
John Nicholas