Analyzing Performance

Use the Analyze Performance task when you want to get detailed information about which methods in your application are using the most CPU time. The Analyze Performance task will also tell you how many times each method has been invoked. Clicking the Analyze Performance button expands it (shown in Figure 15-8).

Figure 15-8. Analyze Performance options

Surviving Generations and Memory Leaks

To understand Surviving Generations, you have to think about the JVM's Garbage Collection process. Every time the garbage collector runs, each object either survives and continues to occupy heap memory, or it is removed and its memory is freed. If an object survives, then its age has increased by a value of 1. In other words, the age of an object is simply the number of garbage collections that it has survived. The value of Surviving Generations is the number of different object ages.

For example, assume there are several objects that were all allocated when your application first started. Further, there is another group of objects that were allocated at the mid-point of your application's run. And finally, there are some objects that have just been allocated, and have only survived one garbage collection. If the garbage collector has run 80 times, then all of the objects in the first group will have an age of 80, all of the objects in the second group will have an age of 40, and all of the objects in the third group will have an age of 1. In this example, the value of Surviving Generations is 3, because there are three different ages among all the objects on the heap: 80, 40, and 1.

In most Java applications, the value for Surviving Generations will eventually stabilize. This is because the application has reached a point where all long-lived objects have been allocated. Objects that are intended to have a shorter life span will not impact the Surviving Generations count because they will eventually be garbage collected.

If the Surviving Generations value for your application continues to increase as the application runs, it could be an indication of a memory leak. In other words, your application is continuing to allocate objects over time, each of which has a different age because it has survived a different number of garbage collections. If the objects were being properly garbage collected, then the number of different object ages would not be increasing.

You can either profile the entire application or just parts of it. Choosing to profile the entire application means that all called methods get instrumented. A large amount of instrumentation can slow performance dramatically, so this option is best used on smaller applications. An additional factor is that profiling your entire application will create a large amount of profiling information that you will have to interpret.

When profiling web or enterprise applications, an additional option is available when Entire Application is chosen: Profile Application Server Code. It is off by default. Turning it on dramatically increases profiling overhead. Similarly, when profiling a NetBeans module or module suite, an additional option is available: Profile the Entire IDE. It is off by default.

If you suspect that certain parts of your application are causing performance problems, then profiling just those parts may be the best approach. If you choose to profile only part of your application, then you must select one or more root methods. Select root methods by either clicking Select, or prior to starting the profiling session use the Tools | Add As Profiling Root Method menu option.

Regardless of whether you choose to profile your entire application or only parts of it, you can specify filters. Filters specify classes that should be either included or excluded from the instrumentation done by the profiler. The Filters list has three entries:

• Profile All Classes. An empty filter, so choose this entry when you want no filtering.

• Quick Filter. This entry displays a dialog box where you can specify a simple filter.

• Exclude Java Core Classes. This is a predefined custom filter that lists the following packages: java., javax., sun., sunw., org.omg.CORBA, org.omg.CosNaming., COM.rsa. Select this entry to exclude the methods of all classes in the listed packages and any child packages.

To create your own custom filters, click Customize Filter. Filters are specified by package name; an asterisk (*) is not necessary but if it is used it must be at the end of the package name.

Clicking Run causes the IDE to start your application and then begin the profiling session.

Viewing Live Results

While your application is running you can watch the amount of time used by individual methods. Select Profile | View | Live Results or click the Live Results icon in the Profiler Control Panel to display the Profiling Results window (shown in Figure 15-9).

Figure 15-9. Live results while analyzing performance

This window displays all methods that have been invoked at least once. The default sort order is by descending self time, so the methods in your application that are using the most time are displayed at the top of the list. The amount of time used is displayed in two columns, one with a graph to show the percentage of time spent in each method and the other with text that displays the raw time value and the percentage. The number of invocations is also shown. The profiler will update these values as your application runs.

To change the sort order, click a column header. This will sort the table in descending order using the values from the column. Click again to sort in ascending order. Clicking the Hot Spots Method column will sort the table by package, class, and method name. To find a specific method more quickly, click on Method Name Filter at the bottom of the table and then enter the method name.

Taking a Snapshot of Results

To see more detailed information, select Profile | Take Snapshot of Collected Results or click the Take Snapshot icon in the Profiler Control Panel. The CPU snapshot window is displayed, with the time of the snapshot as its title (shown in Figure 15-10).

Figure 15-10. Results snapshot while analyzing performance

The CPU snapshot window initially displays its Call Tree tab, which shows the call trees, organized by thread. If root methods were selected, then the Call Tree is displayed expanded so that those root methods can be seen. To switch to the Hot Spots view, just click the Hot Spots tab. It is usually helpful to see the execution path used by your application to get from one or more of the root methods to the hot spots. In order to do that easily, click the Combined tab. This tab shows both the Call Tree and the Hot Spots. Clicking a method in the Hot Spot list will find that method's entry in the Call Tree, making it easy to see the relationship between the root method and the hot spot (shown in Figure 15-11).

Figure 15-11. Combined view while analyzing performance

The Info tab displays a summary of the snapshot information: date, time, filter settings, etc. The icons along the top of the snapshot window allow you to save the snapshot, control the granularity of the snapshot (method, classes, or packages), and search the snapshot.