TOC PREV NEXT INDEX

5 Using the CPU profiler

The purpose of the CPU profiler is to understand in which methods your program spends its time in. Using the CPU profiler involves the following steps:

· Launch a Java program (or attach OptimizeIt to it)
· Start the CPU profiler
· Use the Java program to recreate a situation where the program is slow
· Stop the CPU profiler

OptimizeIt then gives you a per-thread description of the time spent in each method or CPU used during the test session.

The OptimizeIt CPU profiler helps you understand what to change in your program to improve its performance.

5.1 Recording a test session

The following procedure describes how to create a test session with the OptimizeIt CPU profiler:

To record a test session

1. Click the Start Java Program button.
2. Click the Show CPU Profiler button.
3. Click the Start/Stop CPU Profiler button.
4. Exercise the Java program to recreate a performance problem.
5. When the test program completes the action, click the Stop button.

The OptimizeIt window shows the CPU usage for each thread during the test session.

5.2 Understanding the profiler output

After you have recorded a test session, OptimizeIt displays information describing the time spent in each method, or the CPU usage in the Java program. The following screen shot shows the OptimizeIt CPU profiler output:

The top section displays how the time was spent or how CPU was used during the test session. In the example above, 40.7% of the time was spent painting dirty regions (RepaintManager.paintDirtyRegions()), while1.73% of the time was spent retrieving the "RepaintManager:.

Icons indicate the meaning of each line:

The method immediately calls another method

The method actually consumes time or CPU

By pressing the Reverse Display button, you can reverse the top view to look at the backtrace tree from the leaves to the root. This view can be useful when you need to focus on methods or lines of code rather than broad features in your test program.

The bottom section displays the methods that were used during the test session, sorted by "hot spots." These are methods where the most time was spent. The time shown is the time the program spent in a method, no matter where the method was called from. The purpose of this view is to understand if a single method acts as a bottleneck and can be optimized to speed up all the tested features.

To display the code corresponding to a line in the display, select the line, then click the Show Source Code button. You can also double click the line to show the source code. For more information, see "Viewing source code" on chapter 7.5.

The graph on the top represents the sampling period of the selected thread. The colors in the graph indicate the state of the thread each time the sample occurred:

· Green dots mean that the thread was using the CPU
· Red dots mean that the thread was waiting on a condition
· Gray dots mean that the thread did not exist at the sampling time.

To show all threads and thread groups, click the graph (or the drop-down box arrow on the right side of the graph). The following screen shot shows the graph:

In this graph you can select a thread or thread group. Selecting a thread group shows how the time was spent for all thread and thread groups belonging to the thread group.

Refining the CPU Profile display

The Inspector window provides options to refine the CPU profile results. To open the Inspector window, click the Inspector button.

The Inspector window contains the following options for the CPU profiler:

Option Description
Display precision

Controls the granularity of the profiler output. By default the data is organized by method; changing the granularity allows you to organize the data by line of code.

Display CPU usage only

Displays only the pure CPU usage and excludes any methods where the profiled thread was waiting for a condition.

Sampling period

Controls the granularity of the profiler output. Use a small value for a short test session and larger value for a long test session. Usually this value varies between 1 and 100 ms.

5.3 Advanced CPU profiler options

With JDK 1.2 OptimizeIt provides two kinds of CPU profiler:

Sampler

A sampler is a profiler that interrupts all running threads every p period. Once all threads are interrupted, it records what each thread is currently doing and whether each thread is currently using CPU. It then resumes all running threads. p is called a sampling period.

Instrumentation

An instrumentation is a profiler that intercepts method invocations. Each time a method is called the profiler records the fact that a method was called and gives the control back to the application. The profiler also intercepts when a method returns from executing and records the amount of time/CPU that was spent in the method.

Both profilers have different domain of application. The following table shows pro and cons for both profiler types:

Profiler type Advantage Inconvenient
Sampler · Very low overhead: the tested application runs 10% slower with the profiler running.
· Low memory overhead and excellent scalability.
· Since the profiler pauses all threads before recording any information, a sampler does not distord performance related data.
· Since a sampler is not based on method invocations it can detect performance bottlenecks within methods.
· Lack of precision. A sampler precision is not greater than its sampling period.
· Cannot record number of method invocations.
Instrumentation · Very good precision: each time a method is invoked, it is recorded.
· Possibility to measure precision in microseconds.
· Possibility to record the number of times a method gets invoked.
· Lack of scalability: an instrumentation needs to record a lot of information.
· Information distortion: the instrumentation profiler is actually running in the tested program threads. All method invocations are slower. Even if the profiler compensates, this can lead to distorted results.
· Large overhead: the tested application runs several times slower with an instrumentation profiler.

The sampler is very good at profiling a large amount of code for a long time. The instrumentation is very good at precisely profiling small amount of code. The instrumentation is also very useful to understand if a method is slow or if it is called too often.

The following table shows when to use each profiler:

Profiler type Application
Sampler · Profiling an application for a very long time. E.g.: a server overnight.
· Profiling a feature that requires a lot of different code. E.g.: the startup of a large GUI based application
Instrumentation · Profiling anything that executes in less than a few hundred milliseconds. E.g.: a menu action
· Profiling a system that has many threads executing many small requests. E.g.: a servlet

The Inspector window contains the following new options for the instrumentation profiler:

Option Description
Precision

Controls whether the profiler has microsecond precision or millisecond precision. The microsecond precision has more overhead.

Filters

To minimize instrumentation overhead, a filter can be used to exclude any methods that need less than n ms to execute.

Note: In order to minimize overhead, inspector options for the CPU profiler in JDK 1.2 are no longer real-time. When an option is changed, you have to start a new recording session for the change to take effect.

Intuitive Systems
http://www.optimizeit.com
optimizeit@intuisys.com
TOC PREV NEXT INDEX