![]() | The Java Developer's Guide to Eclipse |
Eclipse’s architecture is designed to enable the discovery of extensions to its environment at runtime. This "pay as you go" approach enables Eclipse to act as an integration platform for literally thousands of plug-ins on a single installation. There are, however, means by which this benefit can be unwittingly defeated, thereby increasing startup time and memory consumption. Fortunately, as you learned in Chapter 32, Performance Tuning, plug-in developers have tools at their disposal specifically designed to help track down these problems.
The Runtime Spy will help you improve startup performance of an Eclipse-based application by detecting which plug-in(s) in your application are potentially being activated prematurely. In other words, it helps you enforce two of the first rules of improving startup performance:
A common tenet of both goals is defer code execution whenever possible.

Follow the steps below to install the Runtime Spy:
plug-in_development\eclipse_tools\update_site directory on the book's CD-ROM. Check the
newly added eclipse_tools\update_site and then Next.

Select Next to continue.
plugins directory:
org.eclipse.core.tools (source)
org.eclipse.core.tools.resources (source)
org.eclipse.core.resources.spysupport (source)
The Core Tools are controlled by settings in either an .options file
specified as a command line parameter (e.g., eclipse.exe -debug:file:d:/spy/.options)
or choosing options from the Tracing page of a launch configuration.
Chapter 32 describes how to capture stack traces during class loading using the trace.properties file. The Core Tools
will look for the file specified in the trace/filename option shown above. You can verify that they were loaded by looking
in the console messages:
...
Debug options:
file:/C:/eclipse3.0/eclipse/workspace/.metadata/.plugins/org.eclipse.pde.core/all/.options loaded
Time to load bundles: 160
Runtime tracing elements defined in: C:\eclipse3.0\eclipse\trace.properties... Loaded.
Please note the spelling is trace.properties (singular). Page 762 incorrectly cites traces.properties
– this typo will be corrected in the second printing.
See Chapter 32 for more information on the installation and
use of the Runtime Spy, as well as the table Common Solutions to Eclipse-Specific Performance Problems.
Note 1: The versions of the Core Tools and Eclipse SDK on this CD-ROM are compatible. If you have a more recent version of Eclipse, check the update site (using the Help > Software Updates > Find and Install... choice and the URL http://dev.eclipse.org/viewcvs/index.cgi/platform-core-home/updates/ of the Core Tools developer resources before continuing.
Note 2: The Runtime Spy's memory-related fields (Alloc, Used, and Memory) being zero is a known limitation of this version of the Core Tools. At the time the book was published, this functionality of the Core Tools had not yet been ported to Eclipse 3.0 and it only applies to IBM's JRE with J9 technology (see References).
Note 3: If tracing is not enabled, selecting the Trace
button will display
the message "No stack trace available. See <eclipse install>/plugins/org.eclipse.core.boot/.options". The
.options file is actually located in <eclipse install>/plugins/org.eclipse.osgi/
beginning with Eclipse 3.0.
For a quick glance at what plug-ins are activated, you can use the Plug-in Registry instead of the Runtime Spy, available from the Show View > Other... > PDE Runtime choice:

Toggling its Show Active Plug-ins Only option allows you to quickly see what installed plug-ins the Platform Runtime detected and which are loaded at a given moment. If the list includes any plug-ins that you didn't expect to be loaded, then turn to the Runtime Spy to determine why as described in Chapter 32. To learn about accessing more low-level plug-in loading information, see Exercise 8, Developing a Rich Client Application with Dynamically Added Plug-ins, which describes how to use the OSGi console.
Few things irritate a performance analyst more than discovering that hard-earned improvements were wiped out by newly introduced code or corrections to existing code. Known simply as regressions, they are the bane of every software development project. The key to preventing performance regressions lies in detecting them as early as possible, and that's where the Performance Monitor helps.
To install the Performance Monitor, copy these plug-ins
to your installation's plugins directory
and restart with the -clean command line option (one time only).
org.eclipse.perfmsr.core
org.eclipse.perfmsr.core.win32
org.eclipse.perfmsr.ui
org.eclipse.perfmsr.ui.client
The plug-in projects above, including source, are included on the CD-ROM in the eclipse_tools
directory. If you wish to examine the source code, import the plug-ins
as described in the readme.
Note 1: The versions of the Performance Monitor and Eclipse SDK on this CD-ROM are compatible. If you have a more recent version of Eclipse, get the matching version of the Performance Monitor in the JUnit Plugin Tests and Automated Testing Framework package from Eclipse's download page before continuing.
Note 2: The Performance Snapshots view was tested using the SAX parser included with the Sun JRE, version 1.4.2.
If the view displays the error "SAX2 driver class org.apache.crimson.parser.XMLReaderImpl not found," this may indicate
that the system property org.xml.sax.driver must be set as the
XMLReader class name
for your installed JRE.
See Chapter 32 for additional installation details and usage. Also see the Performance Monitor online help for the steps to instrument your code.
.options settings for using the Runtime Spy
© Copyright International Business Machines Corporation, 2003, 2004, 2006. All Rights Reserved.
Code or samples provided herein are provided without warranty of any kind.