Reading thread 'processor time' quickly

Hi Mike,

First of all, I would like to confirm my understanding of your issue. From
your description, I understand that you need to get the CPU time of a
certain thread. If there is any misunderstandin g, please feel free to let
me know.

As far as I know, we can use both methods you mentioned to get the CPU
time. For the PerformanceCoun ter, we needn't get all the performance
information for all the running threads and processes every time. We can
specify the instance name, category and counter name for the performance
counter object. When we call NextValue method, it only returns the
information we need. Both of the two methods are fast enough on my machine.
Here is an example.

System.Diagnost ics.Performance Counter pc = new
System.Diagnost ics.Performance Counter("Thread ", "% Processor Time");
pc.InstanceName = "WindowsApplica tion82/0";
float f = pc.NextValue();

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

Hi Kevin, thanks for your reply

Your understanding is correct, and your example is exactly one of the
approaches I've tried.

Unforfunately some of the methods that I'll need to measure execute very
quickly, and just calling NextValue() takes on average 0.02s-0.03s, which is
too slow for my needs.

I actually think this is a bit of a dead-end anyway, because from what I can
tell, the resolution of the counter seems to be in the centisecond range
anyway - i.e. when I execute it in quick succession, I get the same values
returned, then the reported values jump up by 0.01s.

As a point of note, I used reflector to have a peek to see what was going on
under the hood of the NextValue() method, and from what I could see it has to
re-create the Counter object, parse all of the instance data into a memory
structure and then find the instance I'm interested in. From the looks of
things this is because when you read a counter you get back all the instance
data in one big chunk of memory. (If you can get at the source code, you
will probably be able to see this in the constructor of
System.Diagnost ics.CategorySam ple)

So, unless there is another way of reading thread timings at a higher
resolution, this may be a no-go!

Thanks,
Mike

"Kevin Yu [MSFT]" wrote:

Hi Mike,

First of all, I would like to confirm my understanding of your issue. From
your description, I understand that you need to get the CPU time of a
certain thread. If there is any misunderstandin g, please feel free to let
me know.

As far as I know, we can use both methods you mentioned to get the CPU
time. For the PerformanceCoun ter, we needn't get all the performance
information for all the running threads and processes every time. We can
specify the instance name, category and counter name for the performance
counter object. When we call NextValue method, it only returns the
information we need. Both of the two methods are fast enough on my machine.
Here is an example.

System.Diagnost ics.Performance Counter pc = new
System.Diagnost ics.Performance Counter("Thread ", "% Processor Time");
pc.InstanceName = "WindowsApplica tion82/0";
float f = pc.NextValue();

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

Hi Mike,

It seems to be by design that the NextValue takes that much time to execute
in .NET framework. If you need the process to be faster, I think you can
try to use WMI instead, which gets value directly. You can try to post in
microsoft.publi c.win32.program mer.wmi newsgroup for wmi question. There
will be more professionals in that group to answer your question. HTH.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

Thanks Kevin, I've used WMI before, so hopefully I'll be able to work this out!

I'll post a quick sample if I get it sorted.

Cheers,
Mike

"Kevin Yu [MSFT]" wrote:

Hi Mike,

It seems to be by design that the NextValue takes that much time to execute
in .NET framework. If you need the process to be faster, I think you can
try to use WMI instead, which gets value directly. You can try to post in
microsoft.publi c.win32.program mer.wmi newsgroup for wmi question. There
will be more professionals in that group to answer your question. HTH.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

I promised a sample, so here it is in case anyone else ever wants it - you'll
need to include the System.Manageme nt namespace.

Sadly, the method call still seems to take around the same sort of time as
the performance counter approach - it's slightly faster, but still in the
same sort of ballpark - and the resolution seems to only be down to ~0.0001s.
I admit my needs are fairly extreme, and for most situations this will be
fine - I expect I'll be able to live with it though!

This sample adds together the user mode time and kernel mode time to get the
overall time.

====

string threadId = AppDomain.GetCu rrentThreadId() .ToString();
string processId =
System.Diagnost ics.Process.Get CurrentProcess( ).Id.ToString() ;

using (ManagementObje ct testObject = new
ManagementObjec t(@"\\.\root\ci mv2:Win32_Threa d.Handle=""" + threadId +
"\",ProcessHand le=\"" + processId + "\""))
{
Console.WriteLi ne(((UInt64)tes tObject.Propert ies["UserModeTi me"].Value +
(UInt64)testObj ect.Properties["KernelModeTime "].Value).ToStrin g());
}

=======

Thanks for your time, Kevin,
Mike

"Mike Goatly" wrote:

Thanks Kevin, I've used WMI before, so hopefully I'll be able to work this out!

I'll post a quick sample if I get it sorted.

Cheers,
Mike

"Kevin Yu [MSFT]" wrote:

Hi Mike,

It seems to be by design that the NextValue takes that much time to execute
in .NET framework. If you need the process to be faster, I think you can
try to use WMI instead, which gets value directly. You can try to post in
microsoft.publi c.win32.program mer.wmi newsgroup for wmi question. There
will be more professionals in that group to answer your question. HTH.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

You're welcome, Mike.

Thanks for sharing your experience with all the people here. If you have
any questions, please feel free to post them in the community.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."