3

I'm doing CPU profiling in VisualVM and look at the results in the call tree.

I have some method, taking a total time X, which is spent in the method itself (Self time), and in subroutines called from the method.

When I add up the times spent in the subroutines, plus the Self time, why doesn't the result equal the total time spent in the method? Note that I'm not talking about milliseconds, but more like 50% or several minutes missing in the balance.

stmoebius
  • 662
  • 11
  • 30
  • Maybe the application is idle for some of the time? Maybe some of the time is spent in native code methods that VisualVM cannot account for? Does it really matter? – Stephen C Aug 27 '12 at 10:27
  • Yes it does matter if I cannot explain 50% of the time spent by my code ;-). Are you sure about the "native code" time? Do you have any pointers to documentation for that? – stmoebius Aug 27 '12 at 12:21
  • No I'm not sure, and I don't have any pointers / evidence. That's why I said "maybe". On whether the 50% point, I'm not convinced that your boss would think it matters ... if the code runs fast enough anyway. – Stephen C Aug 27 '12 at 14:18

2 Answers2

2

It is very difficult to use "self time" to learn anything meaningful except in tiny programs with very shallow call trees.

CPU-only time is also not very useful in any kind of complex program, which can easily spend a large fraction of time in hidden I/O.

It's better to look at

  • inclusive time, not self time
  • wall clock, not cpu time
  • as percent, not as absolute seconds or milliseconds

It's even better to get line-level resolution, not just function or method.

Here's the method I use to find out why time is being spent and how to improve it, and here's an example of what has been done with it. Here's a more extensive discussion of the issues.

Community
  • 1
  • 1
Mike Dunlavey
  • 40,059
  • 14
  • 91
  • 135
0

you need both the total time and inherent (self) time...you also should avoid call trees and instead look at clock timing from a namespace hierarchy perspective (packages, classes, methods, even dynamic tags & marks)

Here is a series of articles which detail what a thorough performance investigation looks like especially when dealing with huge stacks depths beyond +2000 and billion of method invocations in a very short period:

http://www.jinspired.com/solutions/case-studies/scala-compiler

note that each method looks to validate the findings of other methods used...and more importantly there is no single right performance model...there are many right performance models depending on what is being asked and what can be changed...the only bad performance model I know of is one that is sample based in this context though when you have nothing else to do and in a hurry anything little piece of information helps

William Louth
  • 207
  • 1
  • 4