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
The meaning of the CPU Time in the CPU statistics
-
- Posts: 1
- Joined: Thu Feb 16, 2006 4:16 pm
-
- Posts: 6172
- Joined: Wed Aug 11, 2004 8:37 am
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.
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.
-
- Posts: 21
- Joined: Tue Dec 13, 2005 2:53 pm
CPU time affected by invocation count
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 . 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
-
- Posts: 6172
- Joined: Wed Aug 11, 2004 8:37 am
Because instrumented methods run with different speed. For example, HotSpot cannot make as good optimization as it does for original methods.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.
By the way, what is your OS?
-
- Posts: 21
- Joined: Tue Dec 13, 2005 2:53 pm
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.
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.
-
- Posts: 32
- Joined: Sat Sep 11, 2004 9:18 am
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.
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.