Adjust the startup performance of Eclipse with Runtime Spy, part 1th

We hear almost every day that new companies are using Eclipse as their application development platform. Although the installation settings for all of these company's products (not to mention all of the Eclipse organization member company's products) may be tending to be the same, the risk of excessive memory usage and performance degradation is high. This article introduces a very useful but little-known tool, Runtime Spy, to help plug-in developers. Runtime Spy Perspective is part of the team of detectives and tools (spies and tools) of the core team.

Note: The core tools can only run in Eclipse version 2.x. When this article was published, they were not yet running on the Eclipse 3.0 driver; the bug, numbered 47518, described the problem.

Why Eclipse needs to start quickly

The architecture of Eclipse is designed to discover the expansion of its environment at runtime. This architectural extensibility enables many tools to seamlessly integrate into Eclipse. The Eclipse architect realized early in the project that these extensions could not be defined programmatically in client code because the cumulative startup overhead would become unacceptable when Eclipse integrates more and more extensions. As a result, these extensions are defined by Plug-ins.

To maintain flexibility while avoiding startup overhead, the plug-in statically defines its extension in a manifest file (manifest files). The plug-in manifest defines enough information to allow the Eclipse platform to delay loading code while still recognizing the initial impact of the extension. For example, the user interface extension point requires enough information to depict the initial user interface elements (for example, the icon for the provided toolbar buttons and the hot-spot hint (tooltip) text) so that the platform can postpone loading of the plug-in code until the user really chooses a menu option, selects a toolbar button, Load when you open a property page or start a wizard. The initial cost of a plug-in is simply parsing its manifest. Parsing the XML format quickly, the results are saved to disk and can be used next time, so that when a new plug-in or extension is defined, the startup is not significantly affected. However, there are some methods that inadvertently invalidate this benefit, increasing startup time and memory consumption.

Fortunately, the Eclipse plug-in developer can use the Runtime Spy perspective to help track these issues. This paper introduces the core tool plug-in and its Runtime Spy, and introduces some scattered descriptions of its utilities outside the contents of the Readme file.

Install Core Tools

Installation is simple. Just download the core tool package and unzip it to your <inst_dir>\eclipse\plugins directory. Next decide whether you want to detective your underlying Eclipse facility (using the-debug command-line option), or whether you want to detective your Run-time console (using its startup configuration of the tracing page.) We will return to this topic in the "Detective Run Stage". Now let's take a look at the first choice: Detective your underlying Eclipse facility.

First, copy the. options file from the plugins\org.eclipse.core.tools_1.0.2 subdirectory to your <inst_dir>\eclipse directory to enable all available Spy options. This enables all options except class monitoring. To monitor the loading of classes, you must list the packages or plug-ins that contain the classes that you are interested in in the Plugins\org.eclipse.core.boot_1.0.2\trace.properties file. In the "view which classes of Plug-ins are loaded" section, we'll show you how to specify these things.

Then start Eclipse, and don't forget to specify the-debug command-line option, which will read in the <inst_dir>\eclipse directory. Options file. Alternatively, you can identify the location of the. option file as a parameter to the-DEBUG option (for example,-debug file:d:\...\.options).

Detective Table

We assume that you have installed the core tool files and restarted Eclipse. Because the-debug command-line argument has been specified, you will see some startup messages directed to standard output. When in debug mode, these are displayed in a separate command Prompt window, as shown in Figure 1.

Figure 1. A command prompt window showing standard output messages is opened for the-debug option's designation

Now that every Runtime Spy view has been started and running, let's take a quick look at these views. Don't forget that Spy is running in the same workbench as a "spied" plug-in, so there may be some plug-ins activated during the normal process of using the tool itself. This usually doesn't matter, because it only uses the underlying functionality that should have been loaded or sooner or later loaded. One situation may not appear, but it is important to remember that its view is only updated as needed, so Runtime Spy the first time the perspective is opened, it will show only those plug-ins that were already running before it started.

See which plugins are running

Select Window > Open Perspective > Runtime Spy to open four views, as shown in Figure 2.

Figure 2. Runtime Spy Perspective consists of activated Plugins, Loaded Classes, Plugin datasheet, and Stack Trace views