(This does not relate to the basic programming questions I usually ask!)
We have an interesting issue. We have a multi threaded non visual, server app (that runs 10-20 worker threads per process), and it uses a ton of CPU. This is by design.
We cannot profile the real world work load of this code on a developer system. The workload is highly (very highly) variegated. To optimize this code, we need to be able for the production bits to keep a log of which worker jobs take how much CPU.
Our current implementation uses the System.Diagnostics.ProcessThread.TotalProcessorTime to measure, but in .NET v4 does not guarantee the affinity of the logical .NET thread to the ProcessThread, so we cannot be sure what, exactly, we are measuring.
What can we do to measure the CPU use of each thread/each function?
We have heard that an alternate lib for threading is one way, any suggestions?
The split between ProcessThread and Thread dates from .NET 2.0. Inspired by a project inside the SQL Server team that planned on implementing .NET threads using fibers. This project was abandoned, there are no known CLR hosts that don’t use a operating system thread (aka ProcessThread) to implement a .NET Thread.
The only problem you’ll have is matching the ProcessThread with the .NET thread. That was made difficult on purpose in .NET 2.0. The only decent way is to have the Thread itself pinvoke GetCurrentThreadId() and then find a match with the ProcessThread.Id. Once you’re there, you might as well pinvoke GetThreadTimes(). Which also requires OpenThread() to obtain the handle and CloseHandle() to close it again. Visit pinvoke.net for the declarations.