Profiling Tips

Here are some general profiling facts and tips you should be aware of when profiling your applications:

  • Profiler calibration - results accuracy: For each JDK used for profiling, the Profiler needs to perform an initial calibration. The data obtained from the calibration is used to eliminate additional profiling overhead from the collected results in order to deliver more accurate information about execution times. The calibration data is tightly related to system performance (CPU speed, memory & bus throughput etc.) and the JDK version. Each time you change the JDK or make changes that could affect system performance, you should rerun the calibration to ensure that the Profiler collects correct results.
  • Runtime optimizations vs. instrumentation: To get methods call tree and timing, Profiler has to perform instrumentation - this means that the original application's bytecode is slightly modified. If the original code has already been compiled by a JIT compiler to speedup execution, the code is switched back to interpreted execution after instrumentation and can run noticeably slower for some time. This does not necessarily mean that Profiler imposed such a large overhead - if set up correctly, it allows the profiled application to run at nearly full speed. Ideally, profiled code should be run several times after instrumentation to allow the VM to apply runtime optimizations (JIT) again. This ensures that profiling results representing real application behavior in a production environment will be collected.
  • Runtime optimizations - skipping simple methods: Typically, there are many simple methods in an application that don't take any real time when executing as they are compiled to native code or inlined. Instrumenting such methods could lead to significant profiling overhead without any useful results, so profiling getters/setters and empty methods is disabled by default for Analyze Performance - Entire Application profiling. This means that you won't see these methods in call tree or hot spots views. You can change this behavior by creating Custom Profiling Configuration and explicitly enabling profiling getters/setters and empty methods.
  • Runtime optimizations - native routines: Some mathematical functions like Math.sin() are implemented as Java methods calling native code, but you cannot see them in the collected profiling results. They are not visible in the profiling results because of some execution optimizations, which cause these functions to be executed directly in native code, skipping their Java part. In this case, Profiler is unable to detect that such methods have run and does not collect or display the appropriate calls. You should be aware of this when evaluating profiling results. If you are running a 5.0-based JVM, specific functions that Profiler does not detect include Math.sin(), Math.cos() and Math.sqrt(). In a 6.0-based JVM, the functions Math.tan(), Math.abs(), Math.log() and Math.log10() are also not detected.
  • Compile time optimizations vs. real profiling results: When evaluating profiling results, you should be aware of Java compiler optimizations, typically string concatenation or constant expressions evaluation. For example, using System.out.println("Value of a: " + a) results in creating and dealing with StringBuffer, eventually using some parsing/conversion functions to output the value of float/double variable 'a' as a string. The Profiler is unable to detect such optimizations and only reports real runtime flow/behavior of the application's code.
  • Dynamic CPU frequency switching: If the profiled application runs on a machine with dynamic CPU frequency switching technologies (like SpeedStep or PowerNow!), you should ensure that these are disabled. In order to deliver profiling results that are as exact as possible, the Profiler uses static calibration data describing system performance. Changing CPU frequency during profiling would significantly affect the accuracy of the results.


Project Features

About this Project

Profiler was started in November 2009, is owned by Tomas Hurka, and has 61 members.
By use of this website, you agree to the NetBeans Policies and Terms of Use (revision 20160708.bf2ac18). © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo
Please Confirm