-agent:/home/myself/ppProf/prof.jarto your java command line, as in
java -javaagent:/home/user/ppProf/prof.jar -classpath cp org.junit.textui.TestRunner my.test.Class
ppp_Result.txtin the working directory. It contains the number of calls and time spent in each method, in milliseconds. In addition,
ppp_Result_summary.txtlists the packages containing the most frequently called methods and most time-consuming methods.
nanooption to the agent parameter, as in
-javaagent:/home/user/ppProf/prof.jar=nano. ppProf will then use
System.currentTimeMillis()to measure time.
gettimeofday (2)is called in both cases.
gettimeofdayfrom C is about 16 x slower with an SMP kernel, on my test hardware. I'm not kidding. This is really really really expensive, esp. if compared e.g. to a simple getter method. It makes profiling really really really slow.
linuxSMPhackoption to ppProf, as in
countoption to ppProf. In that case, only the calls per method are counted. The overhead for this is usually minimal, and 70% in my worst-case example. You can determine the most frequently called methods this way, exclude their packages or classes from profiling, and turn timing on again.
foo(), and it calls
java.util, the time spent in
hasMoreElements()will be attributed to
scope=-java-sun-org/apache/xerces-org/jdomas an option to ppProf, as in
singleoption to ppProf, you can avoid that overhead. If you use it for multi-threaded code, the results may be strange.
multioption, although it is still experimental.
OutOfMemoryerrors sooner or later.