The meaning of the CPU Time in the CPU statistics

Questions about YourKit Java Profiler
Post Reply
Markham
Posts: 1
Joined: Thu Feb 16, 2006 4:16 pm

The meaning of the CPU Time in the CPU statistics

Post by Markham »

Can you please explain what the meaning of the Time in the CPU statistics. Is. In my test case I get 2000.000 ms. Is this 2000 seconds or 2000 ms.

Is the time needed by a clss-method inclusive elapse time of the method or is it the pure CPU time.

Best Regards

Richard Markham
Anton Katilin
Posts: 6172
Joined: Wed Aug 11, 2004 8:37 am

Post by Anton Katilin »

All times are in milliseconds. Possibly I misunderstand your question. Could you please send a screenshot to [email protected]

The time shown for method is a CPU time. It includes time spent in methods called from that method. There is also "Own time" (shown in Method List) which is a time spent in the method itself.
Paul Gazda
Posts: 21
Joined: Tue Dec 13, 2005 2:53 pm

CPU time affected by invocation count

Post by Paul Gazda »

I have run a standard test that has a wall clock time of 15 seconds. When I run it under "Measure CPU times", the wall clock time is still 15 seconds and the total measured cpu time in the snapshot is 1,422 ms. When I run the same test under "Measure CPU times and count method invocations", wall clock time is 129 seconds and the total measured cpu time in the snapshot is 107,903 ms :shock:. I can understand that the wall clock time would be longer because your documentation says that counting invocations slows performance. But I don't understand why the measured cpu times for the listed methods should change. I would expect that the time spent by each method doing its work would stay the same even if YourKit is spending more time gathering invocation counts. Can you explain this :?:
Anton Katilin
Posts: 6172
Joined: Wed Aug 11, 2004 8:37 am

Post by Anton Katilin »

I can understand that the wall clock time would be longer because your documentation says that counting invocations slows performance. But I don't understand why the measured cpu times for the listed methods should change.
Because instrumented methods run with different speed. For example, HotSpot cannot make as good optimization as it does for original methods.


By the way, what is your OS?
Paul Gazda
Posts: 21
Joined: Tue Dec 13, 2005 2:53 pm

Post by Paul Gazda »

For profiling, I am running Java 1.5.0.6 which runs Tomcat 5.5.9 under Windows XP SP2.

I am not sure I understand your answer, "Because instrumented methods run with different speed. For example, HotSpot cannot make as good optimization as it does for original methods."

To give a specific example, when I measure cpu time only, my method modifyDocExpansions takes 20 ms of cpu time. When I run the exact same test but measure cpu time and count method invocations, modifyDocExpansions takes 6,459 ms of cpu time. Why wouldn't the modifyDocExpansions method show 20 ms in both cases if you are showing the amount of cpu time used by the method? It is as if the work YourKit is doing to count method invocations gets dumped into the time recorded for modifyDocExpansions.
jcompagner
Posts: 32
Joined: Sat Sep 11, 2004 9:18 am

Post by jcompagner »

that last thing is true as far as i know.

For example i have some where in my example a hashmap.put() call that is not measurable at all in "measure cpu time" or if i do it myself with System.currentMillis(). But when i do it with "count invocations" suddenly i see my hashmap.put bumping out as a performance hotspot. And it is because it is hit many many times. Normally that doesn't take anytime but because yourkit is also counting it the total time must be calculated with that counting time also.

Strange thing is if i also count myself in the code so i have 2 static variabbles. totaltime, invokecount and measuere it myself the count is ofcourse equal but the totaltime i measure myself is almost equal to 0.

So i use count invocations only when i use it pure for that looking how many times a method is called. The times you get there are unreliable because the real world times are much better reported by just cpu times only.
Post Reply