download: for Javafor .NET purchase: for Javafor .NET

The profiler may add some overhead to the performance of applications you profile. This overhead may vary from virtually zero to significant, depending on the conditions described below.

Overhead of running an application with profiler

If an application runs with profiler and no measuring is performed (i.e. neither CPU profiling nor memory allocation recording are performed), the overhead depends on the Java version.

• Java 1.3, 1.4 (JVMPI agent):

  The overhead is virtually zero.

• Java 5 and newer (JVMTI agent): the situation is more complex in this case.

  To enable such features as recording object allocation and CPU tracing, the profiler inserts some supporting code into the bytecode of the profiled application by means of bytecode instrumentation. When allocation recording and CPU profiling with method counting are not performed, this inserted code is in inactive state but still adds a small overhead to the performance of instrumented methods (1-5%, depending on the application). The process of bytecode instrumentation itself, of course, also requires some fixed time that depends on the number of loaded classes and their methods.

  In most cases, such overhead is more than acceptable.

  For cases when maximum performance is needed, e.g. if profiling in production, this overhead can be totally eliminated by avoiding bytecode instrumentation. The price you pay is that some features are disabled. But even when they are disabled, you can still capture memory snapshots and profile CPU times, which is enough in many cases (see Solving performance problems).

  You can disable bytecode instrumentation in the following ways:

  • via launch parameters "Disable object allocation recording", "Disable CPU tracing" and "Disable J2EE profiling", if profiling with the help of IDE integration
  • by manually specifying "disablecounts", "disablealloc" and "disablej2ee" options of profiler agent

  Since the greatest share of the overhead described above is caused by instrumentation needed for tracing, as a compromise you can disable this feature alone, keeping the ability to record object allocations on demand.

  There is another, almost negligible, issue with JVMTI. If Java 5 or 6 JVM loads an agent that is capable of profiling heap memory, JVM class data sharing is disabled. This may slightly increase startup time, i.e. the time the JVM needs to load its core classes from rt.jar. For details about class sharing, refer to this page on the Sun website: http://java.sun.com/j2se/1.5.0/docs/guide/vm/class-data-sharing.html

Overhead when measuring is performed

When CPU profiling and/or allocation recording are performed, the profiler adds extra overhead. After measuring is done and turned off, overhead should decrease to the level described above in "Overhead of running an application with profiler".

Snapshot capture

During the capture, the profiled application is paused. The time it takes to capture a memory snapshot depends on the heap size. Capturing memory snapshots of huge heaps takes more time because of the intensive use of the system swap file (if little free physical memory is available).