| Re: [platform-dev] Workspace location, properties and declarative services |
Primarily the focus of removing the Activators are to do with minimising startup time and to enable parallelisation of startup. Currently we’re pretty single-threaded at startup and some of the key blockers are the Acivators. We’ve been working on removing these and getting them out of the critical path for startup over the past few releases. The key reason I’m focusing on Activators is that whenever any resource is accessed (even loading an image from a bundle) that bundle is activated, which incurs the cost of not only executing the Activator but also loading all transient classes required by that Activator (including potentially triggering nested Activators). The net result is that we’re effectively single-threaded on most of our startup code and loading classes ‘just in case’ before they’re strictly needed. In the case of the Workspace, downstream plugins are (generally) calling workspace.addResourceChangeListener() to listen for future events right at startup, which isn’t the kind of thing that needs to be done while the splash screen is being shown …
The whole goal of this is performance related; Lars has been tracking some of the results here: The challenge is trying to reduce the amount of work done during startup, and have resources/classes lazily loaded when needed. The below shows that org.eclipse.core.resources is taking up over 10% of the launch time, when in reality, the startup work could be done in a separate thread: |
The reason I’m focussing on the org.eclipse.core.resources is that it’s part of the key in other bundles that start up later; until Resources starts, nothing else can do. If we can reduce the amount of work we’re doing here, we can save further time. Finally, a lot of the dependent bundles in OSGi are started serially (whether by OSGi’s bundle activator or by Declarative Services bringing dependencies up). If you look at what’s going on (you can see ~approximately these same numbers with the osgi/debug=true flags) you’ll note that they are running on the ‘main’ thread (or the Equinox Start Level, which is code for DS at this point). We can't change the serialisation of classes being loaded, but we do have a shot at getting DS to start components asynchronously, which would bring times down even further, and use some of the many cores that we have in today’s developer machines. |
Data generated via https://github.com/alblue/com.bandlem.osgi.jfrbundlelistener and corresponding blog post; numbers above from the JMC 7.1.1 app processing the OSGi bundle events generated from the above. Timing details of startup can be found at https://www.vogella.com/tutorials/EclipsePerformance/article.html Alex |