NetBeans Profiler 5.5 Tutorial
Expected duration: 70 minutes
The NetBeans Profiler is a powerful tool that provides important information about the runtime
behavior of your application. The NetBeans Profiler can monitor thread state, CPU performance,
and memory usage, and imposes relatively little overhead. This tutorial will show you how to use
the NetBeans Profiler to perform the following tasks:
• Monitor the runtime behavior of an application, including:
• Heap memory size
• Garbage collection statistics
• Thread count
• Thread state: running, sleeping, waiting, blocked
• Determine the CPU time used by an application's methods
• Monitor the creation of objects by an application
• Profile Java SE and Java EE applications
This tutorial assumes you have some basic experience with Java programming.
Software needed for the tutorial:
• Download and install Java 2 Platform Standard Edition version 5.0, Update 4 (or higher).
Note that NetBeans IDE requires a full JDK, not just a JRE. Make note of the installation
• Download and install the NetBeans IDE 5.5 (or higher). Make note of the installation
directory. When prompted for a JDK, specify the v5.0, Update 4 (or higher) JDK.
• Download and install NetBeans Profiler 5.5 (or higher).
The Profiler install program will ask for the NetBeans IDE installation to modify; specify
the installation directory that was used for NetBeans IDE.
• In order to do the final exercise (Profiling an Enterprise Java Bean Module), download and
install the Java EE 5 SDK. The Java EE 5 SDK contains the Platform Edition of Sun Java
System Application Server version 9. (Sun Java System Application Server is also known by
its open-source project name, which is GlassFish). Register Sun Java System Application
Server with the NetBeans IDE by using the IDE's Server Manager (Tools > Server
• Download the tutorial zip file containing the projects used in the exercises.
Notations used in this documentation
• <NETBEANS_HOME> - the NetBeans IDE installation directory
• <USER_HOME> - the user's home directory
• <tutorial_root> - directory into which tutorial zip file is unzipped
• This document uses <tutorial_root> to refer to the directory where the extracted
tutorial zip file used in this tutorial is located. The name of the tutorial zip file is
• Once you have unzipped the tutorial zip file under <tutorial_root>, it will create a
subdirectory called netbeansprofiler. For example, under Windows, if you have
unzipped the tutorial zip file in the root of drive E:\, it will create E:\netbeansprofiler.
Under Solaris/Linux, if you have unzipped the tutorial zip file in the
/home/username directory, it will create /home/username/netbeansprofiler directory.
• Installing and Configuring the Tutorial Environment
• Monitoring Thread State in a Swing Application
• Determining CPU Time Used by a Method
• Profiling Object Creation In Order to Find Memory Leaks
• Profiling an Enterprise Java Bean Module
• NetBeans home page
• NetBeans Profiler project home page
• NetBeans Profiler product page
• Dynamic Bytecode Instrumentation, A New Way to Profile Java Applications
Installing and Configuring the Tutorial Environment
Before continuing with the tutorial, do the following:
• Start the NetBeans IDE and verify that the IDE is running:
• On Windows, double click the NetBeans IDE icon
• On Solaris/Linux open a terminal window, then type
• Verify that the NetBeans Profiler is installed by choosing Profile > Help > About Profiler...
Monitoring Thread State in a Swing Application (15 minutes)
In this exercise, you learn how to use the NetBeans Profiler to monitor thread state in a Java SE
application. This will allow you to diagnose a performance problem in the sample Swing
The Swing library provides graphical user interface components for Java SE applications. Multiple
threads are used by the Swing library and the NetBeans Profiler is a powerful tool that can be used
to understand the amount of processing that occurs on each thread. This understanding can be used
to solve performance problems.
Steps to follow:
1. Choose File > Open Project. Navigate to the
<tutorial_root>/netbeansprofiler/exercises folder. Select the
exercise1 folder and click the Open Project Folder button.
2. In the Projects window right-click the exercise1 entry and choose Clean and Build
Project. Then right-click the exercise1 entry again and choose Run Project. The program
displays its window, shown below.
3. The Seconds Before Notification should be set to 30.
4. Click the Start! button. Notice that it does not redraw correctly.
5. Click the Exit button. Notice that it does not respond at all.
6. In order to see an additional problem, obstruct the view of the window by putting another
window on top of part of it. When you move the other window away, notice that the sample
application does not redraw its window correctly. An example is shown below.
7. After the thirty seconds eventually pass, the message box will be displayed, as shown below.
Click the OK button on the message box.
8. The application window will begin to respond again. Click its Exit button to shut it down.
9. Choose Profile > Profile Main Project.
10.If a dialog box is displayed asking for permission to modify the project build script, click
OK. An example is shown below.
11.The Select Profiling Task dialog is displayed. Click the large Monitor Application button.
12.The Enable Threads Monitoring checkbox should be checked.
13.Click the Run button.
14.If a dialog is displayed that informs you that the Profiler calibration information must first
be collected, click its OK button. An example is shown below.
The Profiler will display a dialog when calibration is complete; click its OK button. An
example is shown below.
To begin profiling, return to step 9, above.
15.The application starts and the IDE displays a Profiler Control Panel, as shown below.
16.The Profiler will display thread state in its main window; an example is below.
Color coding is used to display thread state.
• Green: the thread is either running or is ready to run.
• Purple: the thread is sleeping in Thread.sleep().
• Yellow: the thread is waiting in a call to Object.wait().
• Red: the thread is blocked while trying to enter a synchronized block or method.
17.Locate the sample Swing application's window (the NetBeans IDE window might be on top
of it). Click the Start! button on the sample application and watch what happens to the thread
labeled AWT-EventQueue-0. It will turn green and stay that way for a full thirty seconds, as
shown in the sample below.
This graph shows why the application is not responding. The thread labeled AWT-
EventQueue-0 is the Event Dispatch Thread (EDT) used by Swing to process window
events. In a well behaved Swing application, the EDT spends most of its time waiting and
very little time running; it should only run for the brief amount of time required to dispatch
an event. If the event handlers in the application do not return quickly, however, then the
program will become unresponsive, just like in this example.
18.After the thirty seconds pass, the application's message box will be displayed. Locate that
message box (the NetBeans IDE window might be on top of it) and click its OK button.
Then click the sample application's Exit button to shut it down.
19.The Projects window shares space with the Profiler Control Panel; click the Projects tab to
display the Projects window.
20.In the Projects window expand the exercise1 entry by double-clicking it and then
expand the Source Packages and profilingthreads entries. Right click the
DisplayForm.java entry and select Open.
21.In the Editor window that contains DisplayForm.java, uncomment the block of code
that begins at line 132 and ends at line 157. Tip: If the editor is not configured to display line
numbers, select View > Show Line Numbers.
22.In the Editor window that contains DisplayForm.java, remove (or comment out) the
block of code that begins at line 122 and ends at line 128. It is shown highlighted in the
23.Choose File > Save. You have just removed the code that was using the EDT improperly
and replaced it with a more robust solution. The application should now be much more
24.Choose Build > Build Main Project (or press F11).
25.Choose Profile > Profile Main Project.
26.The Select Profiling Task dialog is displayed. Click the large Monitor Application button.
27.Make sure that Enable Threads Monitoring is checked.
28.Click the Run button.
29.When the sample program displays, click the Start! button. Notice how the Profiler's threads
graph looks different this time; an example is below.
The EDT is yellow and the thread created by the application, which is named "Our
SwingWorker #1" is green. The EDT is not being used to do a time consuming task and as a
result the buttons and other program controls remain responsive.
30.Click the Exit button on the sample program.
31.Right click the AWT-EventQueue-0 thread in the Profiler graph and then select Thread
Details. The Profiler displays a pie chart showing time spent in each state; an example is
This graph can help you determine if your program is spending the correct amount of time in
each thread. The example shown is from after the code was repaired so it shows that the
EDT spent most of its time waiting, which is exactly the behavior it should have.
32.In the Projects window right-click the exercise1 entry and then choose Close Project.
In this exercise you learned how to use the Profiler to start an application and how to interpret the
Profiler's thread information graphs in order to track down a performance problem in a Swing
Determining CPU Time Used by a Method (15 minutes)
In this exercise you learn how to use the Profiler to determine the amount of time spent in one of an
CPU performance problems are usually associated with specific features in an application. For
example, in a reporting system one report might run more slowly than the others. Profiling just the
portion of an application that is experiencing performance problems can dramatically reduce the
overhead imposed by the profiler. In this exercise you will use the NetBeans Profiler to examine
CPU usage in a web application. This sample web application is also used in exercise 3 to show
how the Profiler can be used to find memory leaks.
Steps to follow:
1. Choose File > Open Project. Navigate to the
<tutorial_root>/netbeansprofiler/exercises folder. Select the
exercise2 folder and make sure Open As Main Project is checked. Click the Open
Project Folder button.
2. Choose Build > Clean and Build Main Project from the menu.
3. Then choose Profile > Profile Main Project from the menu. If a dialog box is displayed
asking for permission to modify the project build script, click OK.
4. Click the Analyze Performance button of the Select Profiling Task dialog.
5. Select the Part of Application radio button. Then click the Select button that is next to the
Part of Application radio button. The Specify Root Methods window appears.
6. In the Specify Root Methods window, click the Add From Project... button to add a root
method to profile. The Select Methods window appears.
7. In the Class Name text field, type demo.Performance and then press Enter.
8. Select the processRequest method by clicking on it in the list of Root Methods and
then click the OK button. You have just selected
demo.Performance.processRequest as the root method for performance analysis.
This means that the demo.Performance.processRequest method and all methods
that it calls, and all methods that they in turn call (and so on) will be profiled. Starting from
demo.Performance.processRequest, the Profiler does analysis of the method call
graph to determine which methods need profiling. Only those methods are profiled - the rest
of your application will continue to run at full speed with no profiling overhead.
9. Click the OK button on the Specify Root Methods window.
10.In the Analyze Performance window, select Quick Filter from the Filter list and then click
the "..." button next to the Quick Filter entry to specify methods that should not be profiled.
The Set Quick Filter window appears. Verify that the Exclusive radio button is selected.
Then enter org.apache into the Filter Value text field and click the OK button. All
methods in the org.apache package (and child packages) will not be profiled - even if they
are called from the root method that was selected. This reduces profiling overhead and filters
out information that is not relevant.
11.In the Select Profiling Task window, click the Run button. If a dialog is displayed that asks
for calibration information, click its OK button; after the Profiler displays a dialog indicating
calibration is complete, click that dialog's OK button.
12.The IDE will start the bundled Tomcat server and display the web application's index.jsp
page in a web browser window. At the same time, the Profiler will run in the background.
Note: By default, the index.jsp page will be displayed in the browser window that has focus;
you might want to open a separate browser window so that you can read these instructions
while running the web application.
13.Since you have chosen demo.Performance.processRequest as a root method, you
need to use the portion of the web application that causes that root method to run: In your
web browser, click Performance Problems to go to the Performance demo page. On the
Performance demo page, enter 123456 in the input text field. The optimized option should
not be checked. Click the Submit Query button to calculate the largest prime number that is
less than or equal to 123456.
14.It will take a couple of seconds before the response appears because the algorithm used for
calculating the largest prime number has some performance problems. Also, the Profiler
imposes some overhead when monitoring the performance of the processRequest
method. After the result 123449 displays in your browser, click the button or choose
Profile > Take Snapshot of Collected Results. Click the Combined tab at the bottom of the
CPU usage snapshot. The Profiler displays the latest performance results, as illustrated
The top window shows the complete method call graph beginning with the root method. The
bottom window is a flatter depiction; it shows the Hot Spots in the application - those
methods that took the most time to execute.
15.To examine and interpret the results, notice that the processRequest method ran for a
total of 3745 milliseconds (ms). Note, however, that very little time was spent running the
instructions of the processRequest method itself - the "self time" for
processRequest is only 4.5 ms. The vast majority of the time was spent in methods
called by processRequest. The Hot Spots displayed in the bottom window are sorted by
"self time." By looking at that list you can see that the calculate method took up 97.8%
of the execution time. This is not surprising given the amount of work the calculate
method has been given to do.
16.To help you decide how your application can be optimized, the NetBeans Profiler helps you
identify bottlenecks in your code that were not expected or that will prevent your application
from scaling well. Click the calculate entry in the hot spot list to investigate exactly
where the time went; this will update the call graph window so that calculate is shown.
Since the calculate method does not call any other methods, right-click the
calculate entry and choose Go To Source so that you can examine the source code. You
will discover it uses a very inefficient algorithm that should be redesigned.
17.Choose Profile > Reset Collected Results to clear the Profiler's buffer. To compare
calculate's runtime to an optimized algorithm calculate2, check the optimized
option over in the web browser before clicking Submit Query. Wait for the result, then
choose Profile > Take Snapshot of Collected Results again. Notice that the
processRequest method ran for only 8.6ms and the calculate2 method needed only
18.Note: The next exercise will pick up where this one left off, so do not close any windows.
In this exercise you learned how to have the Profiler do performance analysis on a single method
and all the methods it invokes.
Profiling Object Creation In Order to Find Memory Leaks (20
As a follow-on to Exercise 2, in this exercise you will learn how to switch from one type of
profiling to another and more importantly, how to interpret some of the profiler's graphs in order to
monitor the creation of objects by an application. An example memory leak will be shown.
Steps to follow:
1. This exercise picks up where Exercise 2 left off, so be sure to follow the steps in Exercise 2.
2. Choose Profile > Modify Profiling from the menu.
3. In the Select Profiling Task dialog, click the large Monitor Application button.
4. Click the Run button. The IDE displays the Profiler Control Panel on the left. Click the
button or choose Profile > View > Telemetry Overview. The NetBeans Profiler displays
three graphs in the output window at the bottom, as illustrated below (click for full size).
In the graph on the left the red shading indicates the allocated size of the JVM heap. The
purple overlay indicates the amount of heap space actually in use. In the example above the
allocated heap size at the last update was over 10 megabytes. Of that a little over 5
megabytes is actually being used to hold Java objects.
The graph on the right shows the count of active threads in the JVM.
The graph in the center shows two important heap statistics.
• The blue line (which is at the very bottom of the graph in this example) is the
percentage of execution time spent by the JVM doing garbage collection and is
graphed against the y-axis on the right edge of the graph. Time spent by the JVM
doing garbage collection is time that is not available for it to run your application. So
if the blue line indicates a large percentage you may want to consider tuning the JVM
by configuring a larger heap size (refer to the -Xmx parameter documentation) or
perhaps switching to a different garbage collection algorithm.
• The red line is surviving generations and is graphed against the y-axis scale on the
left edge of the graph. The count of surviving generations is the number of different
ages of all the Java objects on the JVM's heap, where "age" is defined as the number
of garbage collections that an object has survived. When the value for surviving
generations is low it indicates that most of the objects on the heap have been around
about the same amount of time. If, however, the value for surviving generations is
increasing at a high rate over time then it indicates your application is allocating new
objects while maintaining references to many of the older objects it already allocated.
If those older objects are in fact no longer being used by your application then your
application is wasting (or "leaking") memory.
5. The Profiler can do detailed analysis (also referred to as instrumentation) of CPU
performance or memory usage, but it cannot do both at the same time. To find out detailed
information about the allocation and garbage collection of objects on the JVM's heap you
will modify the Profiler's settings. Click the button or choose Profile > Modify Profiling.
6. Click the Analyze Memory Usage button.
7. Select the Record both object creation and garbage collection radio button.
8. Check the Record Stack Trace for Allocations check box.
9. Click the OK button.
10.Now that you have chosen to analyze memory usage you need to use the application in order
to determine whether it is using memory efficiently. In your browser click the Back button
until the application's index.jsp page is re-displayed. Then click the Memory Leak button to
go to the MemoryLeak demo page.
11.On the MemoryLeak demo page, click Start Leaking.
12.Notice the spike in the Surviving Generations graph, as shown in the example below. This
indicates a possible memory leak.
13.Choose Profile > View > Live Results. The Profiler will display a dynamic view of the
objects allocated in the JVM heap. By default it is sorted by the number of bytes used by all
instances of each class. Since a memory leak is suspected, click the Generations column to
sort the display by the number of different object ages for each class. An example of the
resulting display is shown below.
The columns provide object allocation and memory usage information.
• Allocated Objects (third column from the right) is the number of objects that the
Profiler is monitoring. In this example, there are 23 instances of float that are
being monitored. By default this number will be approximately ten percent of the
objects actually allocated by your application. By monitoring only a subset of the
created objects the Profiler is able to dramatically reduce the overhead it places on
the JVM, which then allows your application to run at close to full speed.
• Live Objects is the number of the Allocated Objects that are still on the JVM's heap
and are therefore taking up memory.
• The two Live Bytes columns show the amount of heap memory being used by the
Live Objects. One column displays a graph, the other displays text.
• The Avg. Age value is calculated using the Live Objects. The age of each object is
the number of garbage collections that it has survived. The sum of the ages divided
by the number of Live Objects is the Avg. Age.
• The Generations value is calculated using the Live Objects. As with Avg. Age, the
age of an object is the number of garbage collections it has survived. The
Generations value is the number of different ages for the Live Objects.
14.As the program continues to run, the Profiler will update the display. Keep your eye on the
entries for float and double. Notice how their generation values continue to
increase. As a result, float and double continue to move higher in the list.
Eventually they will be displayed at the top of the list, right under
java.util.HashMap$Entry, which also has an increasing value for generations. As
the application continues to run the generations value continues to increase for
java.util.HashMap$Entry, float, and double, but not for any of the other
classes. An example is shown below (click for full size).
15.To find out what is causing the generation values to keep increasing, choose Profile > Take
Snapshot of Collected Results. Sort the resulting display by Generations. Right-click the
entry for double and then choose Show Allocation Stack Traces. The Profiler displays
all the methods that have allocated one or more double objects. An example is shown
below (click for full size).
Note that of the methods that have allocated double objects, only one method has
created double objects that have a high generation value. That method is run(), in the
aptly named demo.memoryleak.LeakThread class.
16.Right-click the entry for the run() method and choose Go To Source... The Profiler
displays the source code, as shown below.
Note that double and float objects are being allocated and then placed into a
HashMap. They are never removed, however, which means the references held by the
HashMap prevent the JVM from ever garbage collecting those objects. This is a pretty
typical Java memory leak: objects are placed into a Map and then forgotten. Since the Map
used in this example is a HashMap, the associated java.util.HashMap$Entry
objects are also leaking.
17.Extra Credit: If you go back to the Memory Results tab and right-click the entry for
java.util.HashMap$Entry and choose Show Allocation Stack Traces you will see a
more interesting list of stack traces. Experiment with expanding nodes in the stack traces to
see if you can easily find the call that was made by the run() method in the
18.End the profiling session by choosing Profile > Stop or click the button.
19.In the Projects window, select the exercise2 entry and then choose File > Close Project
from the menu.
In this exercise you learned how to use the Profiler to monitor the creation of objects by an
application. You saw the types of information provided by the Profiler when an application has a
Profiling an Enterprise Java Bean Module (20 minutes)
In this exercise, you learn how to profile Enterprise Java Beans (EJBs) by using the specific support
provided in the NetBeans Profiler. You will also learn how to best use the profiler's filters to control
both profiling overhead and the amount of information that is reported.
The NetBeans Profiler has specific support for profiling EJBs. This makes it easy to, for example,
start a profiling session and then run a separate application that invokes the profiled EJBs. Since
EJBs run in an application server, specific techniques are needed to minimize profiling overhead.
Tools are also provided to help find the calls made to EJBs on separate threads.
Steps to follow:
1. Choose File > New Project.
2. Under Categories expand the entry for Samples. One of the entries under Samples is
Enterprise - click the entry for Enterprise.
3. Under Projects click the entry for InterceptorStateless, then click the Next button.
4. For the Project Location field, specify a folder for the project files or accept the default.
Click the Finish button.
5. The NetBeans IDE creates three projects from its catalog of sample projects. All three
projects are displayed in the Projects window.
InterceptorStateless-ejb is an EJB module project that produces a .jar file.
InterceptorStateless-app-client is an enterprise application client project that produces a .jar
file. InterceptorStateless is an enterprise application that produces an .ear file.
6. Right-click InterceptorStateless and choose Build Project from the context menu. Since
InterceptorStateless is dependent on the other two projects, they will be built as well.
7. Right-click InterceptorStateless-ejb and choose Profile Project from the context menu. If a
dialog box is displayed asking for a Java Platform to use, choose the default platform. If a
dialog box is displayed asking for permission to modify the project build script, click OK.
8. In the Select Profiling Task dialog, click on the Analyze Performance button.
9. Click the Entire Application option. Verify that the Profile application server startup option
is not selected.
10.Select Quick Filter from the Filter list and then click the "..." button next to the Quick Filter
entry to specify a filter for the methods that should be profiled. The Set Quick Filter window
appears. Select the Inclusive radio button. Then enter
enterprise.interceptor_stateless_ejb into the Filter Value text field and
click the OK button.
All methods in the classes of the enterprise.interceptor_stateless_ejb package (and child
packages) will be profiled - no other methods will be profiled. When profiling a large
application or when profiling Java EE components such as EJBs, it is very important to
specify a filter when profiling the entire application. Otherwise, the amount of overhead
introduced by the profiler could have a significant impact on performance.
11.Click the Run button. If a dialog is displayed asking you to stop the bundled Tomcat server,
click OK. It will take a moment for the IDE to start the application server in profiling mode,
deploy the sample application, and then do the profiling instrumentation. Eventually you
should see a BUILD SUCCESSFUL message in the IDE's Output window, as highlighted in
the example below.
12.In the Projects window, right-click the entry for InterceptorStateless and choose Run Project
from the context menu. The IDE will actually run the InterceptorStateless-client-app. It is a
simple command line utility that calls a method on one of the EJBs and then reports the
results, as shown below.
13.Choose Profile > Take Snapshot of Collected Results. The CPU results window will open,
as shown below.
The CPU results window lists threads; the exact names listed might vary from one run of an
application server to the next.
14.The methods of an EJB are always invoked on a thread chosen from the application server's
thread pool. So to see the top-level methods that are being invoked, expand one or more
threads, as shown below (click for full size).
This list of methods is particularly useful when you are profiling an application with which
you are not very familiar. By specifying an inclusive filter that limited profiling to the
packages of the application's EJBs you can easily see the top level methods that get invoked.
In this example, the checkIfNull() method of the NullChecker class is a top level method, as
are the constructors for the ArgumentsChecker, NullChecker, and StatelessSessionBean
15.Note that the relative amount of time used by those constructors is very small, so further
information on them is not interesting. It would be helpful, however, to investigate the time
used by the checkIfNull() method. To learn more about how the time was spent in the
checkIfNull() method, expand the entries under it; an example is shown below (click for full
Because the filter was set to only include methods in the classes of package
enterprise.interceptor_stateless_ejb (and sub-packages), there is some information missing
from this display. Specifically, the amount of time spent in methods from other packages is
16.Now that you know the top level (or "root") methods that are being invoked, you can modify
the profiler's settings so that you get more information about those methods without
imposing too much profiling overhead. Choose Navigate > Go to Class (or press
Alt+Shift+O). In the Class Name field of the Go To Class dialog enter NullChecker and then
press the Enter key.
17.The NullChecker.java file opens in the editor. Put the cursor anywhere on line 33, which is
the first line of the checkIfNull() method.
18.Choose Tools > Add As Profiling Root Method. In the Select Settings Configuration Dialog,
click the entry for Preset: Part of Application and then click the OK button.
19.Choose Profile > Modify Profiling
20.The Modify Profiling Task dialog is displayed. In its Analyze Performance section, click the
Part of Application option.
21.Click the Select button that is next to the Part of Application option. The Specify Root
Methods dialog should display and list only one method: checkIfNull().
22.Select Profile All Classes from the list of Filter options. The Analyze Performance section
should now look like the example below.
You have just changed the settings so that only a single root method is profiled. Note,
however, that the NetBeans Profiler will analyze that root method and will also perform
profiling of all methods that the root method calls. This analysis is done recursively, so that
the entire call graph from the root method is profiled. Now that the profiling has been
limited to just the methods that are really of interest, the filter is changed so that profiling is
not limited to only those methods in the enterprise.interceptor_stateless_ejb package.
23.Click the OK button at the bottom of the Modify Profiling Task dialog
24.In the Projects window, right-click the entry for InterceptorStateless and choose Run Project
from the context menu.
25.Choose Profile > Take Snapshot of Collected Results. A new CPU results window will
26.Click the Hot Spots tab at the bottom of the CPU results window. The result should look
similar to the example below (click for full size).
If you click on the tab for the window that contains the CPU results obtained earlier, you can
compare the Hot Spots listed in each window. Because of the filter that was applied, the
earlier snapshot only contains methods from the enterprise.interceptor_stateless_ejb
package. It is important to note, however, that the filter used earlier was necessary in order
to prevent introducing excessive profiling overhead - by using that filter you were able to
identify the top level method of interest in the EJBs being profiled. With that method set as a
root method and the filter removed, the profiler can provide complete details about where
time is being spent - and in some cases that time is in methods that are outside of the
27.In the newer CPU results window, click on the entry for the initUpperCase() method and
then click on the Combined tab at the bottom of the window. The result should look
something like the example below (click for full size).
You can easily see the relationship between checkIfNull() which was selected as a root
method, and the initUpperCase() method that is selected in the Hot Spots list. Notice that in
the Hot Spots list, the initUpperCase() method was invoked two times. If you look at the
Call Tree display, the initUpperCase() method was invoked only once. This disparity
happens frequently when profiling code that is running in an application or web server - the
Call Tree is displayed by thread. The Hot Spots are listed by method, with invocations
across all threads aggregated. To find the other invocation of the initUpperCase() method,
click the Find Next Occurence button in the Call Tree window. The Call Tree window
will highlight the other invocation of initUpperCase(), even if it was on a different thread.
28.Choose Profile > Stop.
In this exercise you learned how to use the Profiler to examine the performance of EJB methods.
You learned how to identify a root method and then get detailed information about the methods
invoked by that root method.
Congratulations! You have successfully completed the NetBeans IDE 5.5 Profiler Tutorial.