Tracing Eclipse components. This article describes how to trace and perform performance analysis on Eclipse plug-ins and RCP applications.
1. Eclipse Performance
This article gives pointers how to analyze Eclipse performance issues.
One of the things not covered in detail is the creation of performance traces via the PerformanceStats class.
See Gathering performance statistics for more details.
Also the projects runs frequently automated performance tests see automated tests to continuously run benchmarks.
2. Monitoring the interactive UI performance with the UI freeze monitor
The Eclipse IDE includes an interactive UI performance measurement feature.
You can activate this tracing via
If activated, a stack trace is written to the Error view, in case a UI freeze occurs.
You should report such freezes to https://bugs.eclipse.org/ to that the team can fix these.
3. Yourkit
3.1. What is Yourkit?
Yourkit is a commercial tool for performance tracing and analysis. You require a license to use it but Yourkit offers free licencses to Open Source projects.
To install Yourkit, you need to download if from Yourkit download. Depending your platform you can the installer (Windows) or extract the compressed archive to your system.
On Linux extract it to a folder of your choice. In this folder you find the script bin/profiler.sh to start Yourkit. The Yourkit tooling starts and ask you for the license key and with which IDE it should integrate.
3.2. Using Yourkit to trace Eclipse
To trace IDE tools like Eclipse you need to remove the filter flag.
Also remove the filter for Eclipse packages.
3.3. Using Yourkit from the IDE
To use Yourkit from Eclipse you need to install the Yourkit plug-ins. A description can be found here: https://www.yourkit.com/docs/java/help/complete_eclipse35.jsp
Afterwards you have a new launch configuration available in Eclipse.
To trace for example the startup time of Eclipse, enable the Trace option and start Eclipse.
3.4. Stopping and starting a trace
To stop a trace and to create a smapshot which can be analyzed press the save button.
To start tracing again use start button.
3.5. Reading the performance trace
Once you created and open a performance trace you typically want to find the bottleneck or see the improved runtime of your changed code.
To see bottleneck for a certain thread, open the Call tree - By thread, you may have to click the Calculate button in the bottom part. Select your thread, and sort the methods by Own time. Try to find things which are slow and in your responsibility.
If you are looking for an improvement in a certain method, you can use the Filter button to find this method.
4. Using the build-in tracing facilities of Eclipse
4.1. Using tracing for your IDE
Eclipse provides a tracing facility which can be activated on demand. If activated, additional plug-in informations are written to the console at runtime.
You activate tracing via the -debug start parameter.
Eclipse looks now, by default, for a file called .options in the Eclipse install directory.
The file must contain one key=value pair per line.
If the plug-in prepared that you can see the tracing option in the preference settings. It is also possible to active these tracing options at runtime. The Eclipse IDE preferences as depicted in the following screenshot.
These tracing options are also available for a launch configuration.
4.1.1. Example: Tracing the startup time of plug-ins
In this example you will trace the start time of each plug-in during startup.
For this, create a .options in your Eclipse installation directory with the following content.
# turn on debugging for the org.eclipse.core plugin.
org.eclipse.osgi/debug=true
# turn on execution time of the activator for the plug-ins
org.eclipse.osgi/debug/bundleTime=true
# turn on total execution time of the plug-ins
org.eclipse.osgi/debug/bundleStartTime=trueStart Eclipse via the following command line.
./eclipse -debug|
You can also specify the location of the options file as a URL or a file-system path after the -debug argument. |
In this example the Starting application timestamp describes when OSGi is done with its initialization. The Application Started tells you when the application has been started. Afterwards you can extract the information which interest you the most. For the above example, the following is a small shell script this extracts the time of the activator of each bundle . It also sorts the bundles by this time.
# start Eclipse with at test workspace while piping the output into a file
./eclipse -debug -data ~/test > trace.txt
# get total start time
echo "Total startup time" > tracefinal.txt
grep "for total start time" trace.txt | awk '{print $1 " " $13}' |sort -nr >> tracefinal.txt
echo "" >> tracefinal.txt
echo "Activator times" >> tracefinal.txt
# extract the activation time
grep "to load and start the activator" trace.txt |awk '{print $1 " " $10}'| sort -nr >> tracefinal.txt4.1.2. Example: Tracing the resource plug-in
The following is another example for an .option file in which you trace the resources.
# turn on debugging for the org.eclipse.core.resources plugin.
org.eclipse.core.resources/debug=true
# monitor builders and gather time statistics etc.
org.eclipse.core.resources/perf/builders=10000
# monitor resource change listeners and gather time statistics etc.
org.eclipse.core.resources/perf/listeners=500
# monitor workspace snapshot and gather time statistics etc.
org.eclipse.core.resources/perf/snapshot=1000
# monitor workspace snapshot and gather time statistics etc.
org.eclipse.core.resources/perf/save.participants=500
# debug build failure cases such as failure to retrieve deltas.
org.eclipse.core.resources/build/failure=true
# reports the cause of autobuild interruption
org.eclipse.core.resources/build/interrupt=true
# reports the start and end of all builder invocations
org.eclipse.core.resources/build/invoking=true
# reports the start and end of build delta calculations
org.eclipse.core.resources/build/delta=true
# for incremental builds, displays which builder is being run
# and because of changes in which project.
org.eclipse.core.resources/build/needbuild=true
# prints a stack trace every time an operation finishes that requires a
build
org.eclipse.core.resources/build/needbuildstack=true
# prints a stack trace every time a build API method is called
org.eclipse.core.resources/build/stacktrace=false
# report debug of workspace auto-refresh
org.eclipse.core.resources/refresh=true4.1.3. Implement tracing for your plug-in
Can you also implement tracing for your custom plug-in, see
Using Eclipse Tracing API. To add your tracing options to the preference preference page, to allow users to turn them on at run time, use
extension point the org.eclipse.ui.trace.traceComponents.
See TracingPreferencePage for the implementation of this.
4.1.4. Example: Tracing for key bindings
The tracing functionality of Eclipse allows to you trace which command is associated with a certain key binding. The following listing contains the trace options to enable that.
# turn on debugging for the org.eclipse.core.resources plugin.
org.eclipse.ui/debug=true
org.eclipse.ui/trace/keyBindings
org.eclipse.ui/trace/keyBindings.verbose5. Eclipse Sleak
Eclipse Sleak monitors the creation and disposal of SWT graphics resources. Get it from the SWT Development Tools or install the Eclipse Plugin via the SWT Tools Update Sites.
To activate Sleak, you can use the Tracing tab in your Eclipse runtime configuration.
Alternatively you can also activate it for your Eclipse IDE. For this you have to start Eclipse with the -debug option from the command line. You also need to create a .options file in the Eclipse installation directory with the following entries.
org.eclipse.ui/debug=true
org.eclipse.ui/trace/graphics=trueIf you start your Eclipse IDE, you find the Sleak view under .
Sleak allows you to take a snapshot and create a diff. Clicking on Stacktrace gives you the stacktrace in which the resource was allocated.
6. Eclipse tracing and performance tools resources
6.1. vogella Java example code
If you need more assistance we offer Online Training and Onsite training as well as consulting