The NetBeans profiling tool gives developers the ability to inspect their developed applications while they are running. With it, it is possible to gather valuable information from the state applications are in at a determined moment.
In this recipe we will use the Profiling tool to check:
The project we will use for this recipe is the Document Editor contained within the examples supplied with NetBeans. We will use the Document Editor since sources are provided together with the NetBeans installation, but feel free to apply the concepts in this recipe to your own project.
Since the NetBeans Profiler is already included in the installation package of the IDE there is not much difference from which version to install, but we will continue with the Java bundle provided which can be found at: http://netbeans.org/downloads/index.html.
First we will need to create a project:
To successfully use the profiler we will have to first calibrate it. To do so, please follow the steps below:
Let's start the profiling of our application by monitoring threads:
After monitoring the threads we will dive into profiling CPU performance.
Stop the previous profiling session (this can be done by finishing the execution of the Document Editor application) and follow the steps below:
The next step is to analyze how our application is consuming memory.
Stop the previous profiling session (this can be done by finishing the execution of the Document Editor application).
We will then proceed to the final step of saving snapshots.
With the application still running navigate to the Profiler window and click on Live Results icon.
Once the profiler has been integrated with the DocumentEditor, NetBeans presents the Profile DocumentEditor dialog with Monitor, CPU, and Memory options.
When starting the thread monitoring process, NetBeans will launch a window covering the place where the Java editor is.
This window will present the developer with a graph in which a timeline of threads is shown. These threads can be Running, Sleeping, Waiting, or in Monitor state.
Under the new window the developer has the possibility to change to the other views: Table and Details.
Under Table tab, statistics are presented which detail the Running/Sleeping/Waiting time of each thread, along with the total time of each monitoring thread.
The Details tab presents pie charts and timelines of each of the threads in the application, giving a complete visualization of both timeline and Table views, which is useful for identifying bottlenecks in the application.
It is possible to click on each of the colors in the timeline and navigate to the specified time in the Details sub-tab of each of the threads.
More information about the dialog of ProfileDocumentEditor is as follows:
When the Run button is clicked another window is shown, containing all the controls for the profiling session.
From here it is possible to:
The two options presented in the Analyze Performance section are:
Both of the options will return real-time data.
To see some of the data produced by the CPU profiling session, navigate to the profiler window and search for the Live Results button. Click on it and Live Profiling Results will be shown:
This data results from the time spent in each method, given in both percentage and milliseconds. The number of invocations is also shown in the profiler, which in our case turns out to be one, since we are only checking the startup method.
On Analyzing Memory, NetBeans maps all types, number of instances, and size of the created instances.
This mapping can be more or less specialized depending on which option was selected at the start of the profiling.
If a more specialized information set is required then Record both Object creation and garbage collection. For our example we are recording object creation only.
For the Tracking every number of allocations option we are using 1 which records all information. If using another number, say 5, each interval of 5 created objects will be recorded.
Using this option might degrade performance on slow machines since the amount of data produced is greatly increased, especially if huge production projects are being tested this way. Probably a better way would be to start off profiling subsets of the code instead of requiring all information at once.
After profiling the application it is possible to save snapshots for future references or for comparison.
It is possible to get a better visualization of the whole picture by comparing the application's performance in different circumstances and behavior.
More information is introduced in the There's more section of some of the topics covered in this recipe.
Calibrating and detaching the NetBeans profiler.
Calibrating the profiler ensures that the current installed Java platform will provide more accurate results when dealing with bytecode compiled by the specific version of the JDK installed.
Please be aware that calibrating the profiler with laptops may lead to variable results due to dynamic frequency switching. Also avoid running calibration when the computer is under a heavy load, CPU/memory-wise; also, for more accurate results, run calibration only and close other programs.
Although it is necessary to calibrate the Profiler only once if only one version of the JDK is used, this requirement is no longer true if many different versions of JDK are installed. NetBeans will ensure that calibration occurs if none was ever made for that installed JDK.
By placing the mouse cursor for a prolonged time over one of the graphs NetBeans will display more information related to that particular graph, as shown in the following screenshot:
To compare profiling snapshots:
nbproject/private/profiler
in the project folder.The IDE presents the result window, called Liveness Comparision:
This presents the developer with differences in live objects, bytes, and averages; useful for finding memory hogs throughout the application.
By comparing memory snapshots, developers are able to identify how the application behaves in different kinds of testing and under different loads.
3.129.20.125