Profiler - Analyze Performance

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

  1. Choose Profile -> Profile Main Project ( Profile Main Project ) from the main menu.
  2. Select Analyze Performance in the Select Profiling Task dialog box.
  3. Select one of the following profiling options:
    • Application Performance
    • Part of Application
  4. If desired, specify an existing filter or create a new custom Filter Set for the classes.
  5. 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 ( Live Results ) 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."

    set-quick-filter-dialog

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


Customize filter sets

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.

global filters dialogue

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

 

Project Features

About this Project

Profiler was started in November 2009, is owned by Tomas Hurka, and has 58 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
 
 
Close
loading
Please Confirm
Close