Analyze Performance
You can choose to analyze the performance of the entire target application or limit the profiling to a part
of the application code, even down to a specific code fragment.
How to Analyze CPU Performance in Profiler
- Choose Profile -> Profile Main Project (
)
from the main menu.
- Select Analyze Performance in the Select Profiling Task dialog box.
- Select one of the following profiling options:
- Application Performance
- Part of Application
- If desired, specify an existing filter or create a new
custom Filter Set for the classes.
- Click Run at the bottom of the dialog box to launch the application and
start the monitoring task.
To display profiling results, click the Live Results button ( 
)
in the Profiler window. The results are displayed in the Profiling Results tab.
Profiling options
Application Performance
Application Performance profiles method-level CPU performance (execution time).
You can choose to profile the entire application or a part of the application.
- Entire Application.
In this mode, Profiler instruments all of the methods of the profiled application. Threads emit
the "method entry" event when entering a method and generate
the corresponding "method exit" event when exiting the method.
Both of these events contain timestamps.
This data is processed in real time.
When profiling applications that are deployed to a server (such as enterprise applications and web modules) or
NetBeans modules or suites deployed to the NetBeans platform, you have the option to also profile the server or platform startup.
When this option is selected, the first method executed by the JVM is used as the root method when instrumenting.
- Part of Application.
In this mode, you can instrument and profile a limited subset of the application's
code. When partial application profiling is initiated, profiling data
is not collected until one of the application's threads enters the profiling root method.
Profiling a limited subset of the application's code may greatly reduce the
profiling overhead. Furthermore, for some programs this option may be the only way to
obtain any detailed and/or realistic performance data at all as the amount of generated
data when the entire application is profiled can be so high as to render the application unusable or even
cause it to crash (for example, due to unexpected timeouts).
Filtering Classes
You can further control the temporal overhead (at the cost of reducing the amount of information obtained ) by
filtering the profiled classes. You can select from the following filter options in the
combo box or click Customize Filter to create a custom filter set.
- Profile All Classes
Select this option to run the task without filtering the classes.
- Quick Filter
This choice opens the Set Quick Filter
dialog box, where you can simply enter the filter type and value(s). The filter uses a simple "starts with"
comparison on profiled methods, classes or packages, so the filter value should be only a valid Java identifier. To
specify more than one term, separate the terms with a space or comma (and space), for example
"java., javax., sun."
- Defined Filter Sets
You can select the predefined Profiler filter
(Exclude Java Core Classes) or
define your own Filter Sets by clicking Customize Filter.
(See Creating Custom Filter Sets)
Creating Custom Filter Sets
The Customize Filter Sets dialog box allows you to create, remove or edit defined
Filter Sets by changing their name, type or active Filters. When you create a new filter,
the filter appears in the list of filters in the combo box.
To create custom filters, name your custom filter and choose any combination of
filters from the list of Global Filters. You can add, delete and modify the Global Filters
in the Edit Global Filters dialog by clicking Edit Global Filters.
Note that each Filter Set or Filter has to have a unique name.
Depending on the size of the selected subset, the reduction in the
overhead when profiling a part compared with profiling the entire application
can be dramatic. This is because the application spends less time generating the profiling
data and the tool spends less time processing this data.
More CPU profiling options that affect profiling data collection are available
in the Custom Profiling mode.
Getting accurate results
The Profiler takes advantage of Sun's HotSpot JVM. When running an application, a lot of Java bytecodes
can get compiled into machine code (typically for compilation it's enough
for a method to be executed a few thousand times). If any of the methods in the given
call graph have previously been compiled into machine code, dynamic instrumentation
may initially disturb execution of these methods quite noticeably. The reason
for this is that when a method is instrumented and its original and modified
bytecodes are hotswapped, the new code initially runs interpreted, as in
the beginning of the application execution. It then can get compiled again
under the standard policy. Furthermore, a temporary switch to interpretation
may happen even to some methods that are not instrumented themselves, but
call instrumented methods. For this reason, while Profiler is discovering
the call graph, and for some time afterwards, the application may run considerably
slower than normally and the CPU profiling results obtained during this
period are not representative of its normal execution.
It is recommended
that you run the application for some time after initiating the call graph
instrumentation and then discard the already accumulated profiling results
by choosing Profile > Reset Collected Results from the main menu or
clicking 
Reset
Collected Results in the Profiler window.
(For example, if it's a server-side application, you can make it
process a few hundred or thousand requests.) Profiling results collected
afterwards will match reality much better.
See also
