Community
Participate
Working Groups
Build ID: Eclipse 3.6m6, Sun JVM Cold start: =========== I am testing with an eclipse application that shows the Project Explorer, an editor with a c++-file and the Outline View. I have opened the application with a workspace several times. Now I reboot my machine and open the application on the same workspace. That's my cold-start. Profiling: ========== Profiling the cold start I can see that there is a large contribution of elapsed time from various operations related to loading data from the zipped bundle files. (Opening the zip-files, finding entries and reading data) Using System.nanoTime() I have done some measurements that cumulate the time spent on opening, searching and reading the zipped bundle files. Warm Starts (for comparison): JVM startup-time zip-bundle operations 1.5 13 s 1.3 s 1.6 12 s 1.3 s Cold Starts: JVM startup-time zip-bundle operations 1.5 41 s 18.5 s 1.6 51 s 28.5 s Note: The 1.6 jvm is much worse, because the implementation of ZipFile no longer uses memory mapped files. I have identified 8 bundles for which most of the classes are loaded: (org.eclipse.ui.workbench, org.eclipse.ui.ide, org.eclipse.ui.editors, org.eclipse.jface, org.eclipse.jface.text, org.eclipse.swt.win32.win32.x86, org.eclipse.cdt.core, org.eclipse.cdt.ui and one Wind River specific plugin) When adding in code to pre-read the jar-files for these 8 bundles I can boost the startup time: Cold start with bundle pre-reading for 8 selected bundles: JVM startup-time zip-bundle operations (includes pre-reading) 1.5 35 s (- 6s; 14%) 10 s (- 8.5s) 1.6 35 s (-16s; 31%) 11 s (-17.5s) Note: With the pre-reading Java 1.6 behaves pretty much as 1.5. Proposal: ========= I propose to add an option that allows for providing a list of bundles for which the jar-file shall be pre-read when opened. E.g.: osgi.bundle.prefetch=org.eclipse.ui.workbench,org.eclipse.ui.ide,org.eclipse.ui.editors Furthermore, there is a need for a tracing option that outputs the cumulated time for opening, searching and reading zipped bundle files.
Most of this can already be done with a framework extension with no changes required by the framework. In fact we have such an extension which we are currently thinking of contributing to Equinox. There are other examples of such improvements with no changes to equinox. See http://wiki.apidesign.org/wiki/NetbinoxPerformance
(In reply to comment #1) > Most of this can already be done with a framework extension with no changes > required by the framework. In fact we have such an extension which we are > currently thinking of contributing to Equinox. Tom this sounds very interesting, can you elaborate? From a superficial look at Netbinox, I could not see how we could leverage any work done there. Plus their code is GPL. Did you have anything particular in mind?
In the framework extension we have the following is done. 1) We have the ability to record class/resource loads and determine (learn) an optimal set of resources that are needed to get to a certain point in the application bring up. 2) We then can create a single cache file that contains this optimal set of resources. We have various policies that allow us to control the content and size of this cache file 3) On a cached start we pre-load the complete cache into memory and then free that memory as the resources are loaded during startup. The cache is not a zip file to allow for a very fast initial read into memory of the complete cache. The goal is to put off as long as possible the first ZipFile open/read. 4) We assume that the complete cache will be used up on start up. We have additional opportunities to tweak the cache depending on if large percentages of the cache are not used on restart or if large amounts of resources are loaded which are not cached. I really hope to get our extension contributed in the short-term but it will certainly not make it for Helios. Even if I had approvals to release today it would be too late to consider. But I really want to avoid putting anything this advanced directly into the framework because there are lots of different strategies to take in this area. For example, most modern VMs support some form of class sharing and class caching. Other framework extensions can be written to take advantages of these advanced caching mechanisms in the VMs.
Since the API for framework extensions has been stable for a while, it looks like such a framework extension can be created independent of the release cycle. In fact we have started doing our own framework extension with a simplistic approach for "OS Disk cache warm-up" on first access of certain bundles. In case others are interested, there is good documentation and sample code for framework extensions available: http://wiki.eclipse.org/Adaptor_Hooks http://www.eclipsecon.org/2007/index.php?page=sub/&id=3762 http://wiki.eclipse.org/Equinox_Transforms Equinox Weaving http://it-republik.de/jaxenter/artikel/Getting-Hooked-on-Equinox-1540.html I find the general issue of startup performance interesting from an Eclipse PMC point of view, since platform startup performance is relevant for the Platform itself (as you have pointed out, Netbeans prides itself with fast startup). So, I think that contributing your configurable caching solution would be great for the Community as a whole.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the "stalebug" whiteboard tag.
Some of the the ideas in comment 3 are still interesting. Although not sure how much saving they could bring. I'll leave open in case someone has time to have a deeper look.
