Adjust the startup performance of Eclipse with runtime SYP, part 2nd

Runtime Spy is one of the core tools provided by eclipse.org, a specially designed perspective and a set of views to help you find and troubleshoot plug-in startup performance issues. One of the case studies illustrates how runtime Spy can be used to improve startup performance for IBM WebSphere Studio application Developer. The previous article, the 1th part, introduced the Runtime Spy.

After reading the 1th part of this series, you should have a general understanding of how Runtime Spy can help you find your startup problems. Let's take a few specific examples to figure out how to use it to reduce your plug-in startup time. To make the topic more readable, we will explore some of the issues that have been corrected with the help of Runtime Spy, which is one aspect of the performance improvement of IBM WebSphere Studio application Developer.

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.

Help Eclipse launch quickly

To improve the startup performance of an Eclipse-based application, there are generally two goals:

Delay the activation of the plug-in as much as possible.

Minimize the amount of work involved when activating your plug-in.

The common principle of these two goals is to defer code execution as much as possible. Some of the ways you can use:

Do not load your plugin

What to do? First, follow the ideas of the plug-in extensions for Eclipse itself. Do not forget that many Eclipse extension point definitions require contributors to statically declare enough information to delay the loading of the code until the requested action is required. This is the basic idea of the Eclipse architecture and is reflected in the declaration of the plug-in manifest file. This approach should also be used for your own extension point definitions.

Reduce the number of classes loaded when plug-in initialization

The most common occurrence of the problem is the reference in the Plugin.startup method. Many Plug-ins overload this method to complete their initialization. The ideal solution is usually to have your plug-in delay its initialization until the user requests a specific action for your product. Otherwise, the next best option is to minimize the number of referenced classes and plug-ins. In either case, Runtime Spy can indicate where it may take too much time or trigger the activation of too many other plug-ins.

Reduce CPU utilization during plug-in initialization

Again, the most frequently problematic place is the code for the plug-in's startup method or the code it invokes. The lag initialization of the memory structure can save CPU time and delay the activation of other plug-ins. Another possibility is to derive a separate, low-priority thread at startup, which completes initialization when the system is idle, but this approach requires special attention to handling synchronization.

By delaying the activation of plug-ins, users will be given a more flexible impression of a product. Although the cumulative CPU time is exactly the same, it is broken down into several small chunks over a long period of time, rather than being forced at the start of the task. In particular, there should be no delay in the first call, which is when you start your product or when you open the first perspective, editor, or view, because it is at this point that the user is most concerned about the completion of the work without too much patience.

Then introduce Runtime Spy

Runtime Spy provides you with basic statistics for tracking three accelerated startup methods, as shown in Figure 1.

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

Your first goal is to minimize the entries that appear in the activated Plugins view. For those plug-ins that appear in the list, your second goal should be to minimize the entries that appear in the Loaded classes view. The startup time column in the activated Plugins view will point you to those plug-ins that start longer. The Select button in activated Plugins updates the Stack trace view so that you understand why the plug-in was loaded, and selecting the button in Loaded Classes view will show you why the class was loaded.