Profiler - Custom Profiling

Home > Profiling Tasks > Custom Profiling

CPU Profiling settings

In the Custom Profiling mode, you have complete control over all of the internal profiling settings available. When you choose CPU profiling, you can choose between profiling the entire application, part of the application, or application startup.

Choosing the CPU Profiling option brings up the following settings dialog box (switched to Part of Application):

Custom CPU Profiling Settings - Basic

The dialog box allows you to further refine the following profiling configuration:

  • Methods Tracking: full (Exact Call Tree and Timing) or sampled (Exact Call Tree, Sampled Timing). During CPU profiling, Profiler injects a "method entry" call at the beginning of each profiled method, and a "method exit" call before each return. In the full instrumentation mode, each "method entry" and "method exit" call generates a timestamp, and the time spent in the method is calculated as a difference between these timestamps. In sampled instrumentation mode, timestamps are not taken on every "method entry"/"method exit" call, but only at those that fall approximately at end of each sampling period that you specify.
    For details, see Full Instrumentation vs. Sampled Instrumentation.

  • Instrument new threads started within root methods execution. When checked, this option makes Profiler instrument the code for any thread started after the application entered the root instrumentation method (see Profiling Single-Threaded and Multi-Threaded Applications). For the Entire Application mode this option is set by default and the control is hidden.

  • Use Thread CPU Timer. The timestamps of method entry/exit events can be taken using different kinds of OS timers. By default, absolute timer is used to measure absolute, or wall clock time. Thread CPU timer measures only the time spent executing the given thread. Essentially, the OS suspends this timer every time the CPU stops executing the code on behalf of the given thread, and resumes it every time execution switches back to this thread. This option is available only for the Solaris OS. For details, see Using Different Kinds of Timers.

  • Instrumentation: filter. You can limit the number of classes that are instrumented and profiled by specifying an instrumentation filter.

You can define more profiling settings in the Advanced tab (switched to Part of Application):

Custom CPU Profiling Settings - Advanced

Available options are:

  • Limit number of profiled threads. You can limit the number of threads that are profiled. Every time a thread that has not been previously registered enters the instrumented code, this counter is decremented. When it reaches zero, registration of new threads is stopped. Profiling data is collected only for the registered threads. The counter is reset to the value specified above every time you invoke the Profile > Reset Collected Results ( ). For details, see Profiling Single-Threaded and Multi-Threaded Applications.

  • Instrumentation: scheme. By selecting an instrumentation scheme, you can limit the number of instrumented methods. Usually, it is best if the number of instrumented methods and the number of methods actually called by the application when it is profiled are the same or very close. The default scheme for Part of Application is "Lazy". Usually it is most appropriate when you want to profile a subset of the application code (for example, just one or more servlets running on top of an application server) because it results in the smallest number of instrumented methods. However, total instrumentation may be more appropriate if you want to profile application startup, or an entire application such as a short-running command line utility. For the Entire Application mode "Total" instrumentation is default value and the control is hidden. For details, see Instrumentation Schemes.

  • Instrument/not instrument various special Java methods. When "Instrument Method.invoke()" is checked, all calls done using Java Reflection (i.e. the java.lang.reflect.Method.invoke() call) are followed and instrumented. Otherwise, such calls are not followed. The other two options specify whether Profiler should instrument methods that either get/set object fields, and methods that don't contain any executable code. Typically it does not make sense to instrument these methods, since the HotSpot JVM optimizes them very efficiently and normally their execution time is negligible. When instrumented, however, they may contribute to the profiling overhead noticeably. Check these boxes only if you want to find out whether, or how many times, some of these methods are called.

See also


Project Features

About this Project

Profiler was started in November 2009, is owned by Tomas Hurka, and has 62 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