HOME > Community > Projects > profiler

Using NetBeans Profiler 5.5

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 settings dialog box:

Custom CPU Profiling Settings - Entire Application - Basic settings

When profiling the entire or part of an application, you can refine the profiling configuration by modifying the following Basic and Advanced settings:

Basic Options

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).
This setting is not visible when profiling in Entire Application mode because the option is selected by default.
Exclude time spent in Thread.sleep() and Object.wait(). When selected, these times are not included in the instrumentation.
Instrumentation: Filter. You can limit the number of classes that are instrumented and profiled by specifying an instrumentation filter. For more, see Creating Custom Filter Sets.

Advanced Options

The following options are available in the Advanced options tab.

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.
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: 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.