Kepler Startup Time

STATUS:

The content on this page is outdated. The page is archived for reference only. For more information about current work, please contact the Framework team

Overview

A discussion about Kepler startup times from December 2006- November 2007.

Related Links:

Kepler LibBuilder

Actor Drop Classes

Kepler Startup Time Issues

During the December 2006 SEEK AHM, the issue of startup time was again discussed. Not enough profiling has been done to fully understand the issue. Currently on a P4 1.8 GHz machine with 1 GB of RAM, it takes Kepler ~23 seconds to start.

The discussion at the meeting centered around what, exactly, was causing the slow startup time. Educated guesses ranged from JAR loading/classpath issues to component library parsing. The two main conflicting issues are startup time versus the processing needed to manage the complexity of the application.

It was discussed that a good place to start would be by removing the non-essential components from the kepler application. It was also discussed to have two versions of kepler; the normal version and a kepler light where only a few, essential components would be included with the release and the rest of the components would be downloaded from the repository (similar to the way R does it). The main issue with this approach is that we need to revisit dynamic class loading for the downloaded components.

Timing is an issue with this as well, since we don't have a lot of time left on the grant. We talked about whether this had high enough priority to assign scarce developer resources to it. The consensus was that if there is a quick(ish) fix, that we should do that but we shouldn't delve too deeply into changing basic underlying functionality.

The startup process has been speeded up (especially after the initial startup) by eliminating the loading of ALL actor class files at startup. Loading of classes now occurs when the actor is dropped on the canvas.

Dan Higgins - NCEAS - Nov 2007