I just created a new WPF application which has about 5 windows and makes use of the Xceed Data Grid. After looking in the task manager I saw that this small application had 19 threads running.
Can this be correct? I expected the WPF framework to use 2-3 threads, but not 19. Or am I doing anything wrong?
First, it isn't 19.
When running a "Hello, World!" WPF app, I see 10 threads in Task Manager. When running the same app using the Visual Studio debugger, it uses 19. So, first, factor out 9 of these added as overhead from the debugger.
Now for the 10.
According to a MSDN Magazine article called "Build More Responsive Apps With The Dispatcher", WPF starts out with two threads:
All WPF applications start out with two important threads, one for rendering and one for managing the user interface. The rendering thread is a hidden thread that runs in the background, so the only thread that you ordinarily deal with is the UI thread.
But according to this article, there are lots of basic threads in all managed apps, WPF or not:
There are different types of .NET threads: finalizer, GC, debugger, timer, threadpool, primary and background threads. But not all threads related to .NET are managed.
Starting with the two from WPF, add in the GC and the finalizer to get up to four. Add in the debugger thread (all managed apps have one even when not debugging) to get to five. Add the timer to get to six.
And, attaching a debugger to my WPF app after starting it outside VS, I can see there are two worker threads in the thread pool. This is likely a minimum. This gets my app up to eight.
There are two I cannot account for exactly, but they are likely COM threads for interop (they are definitely not managed threads). The second article I referenced discusses more of these.
But the real moral of the story here is, don't worry about them. If a vanilla "Hello, World!" app uses 10, that is your baseline. Only worry about threads you create beyond this minimum.