[kepler-dev] Kepler timing data

Christopher Brooks cxh at eecs.berkeley.edu
Wed Feb 7 11:28:40 PST 2007

Hi Dan,

I'm swamped with other tasks, but this is all really interesting to

Start times for Ptolemy II 6.0.1 Windows Installer exe
  (1.8 Ghz Pentium M, 1 Gig Memory)

I ran "time ./vergil.exe" and then clicked on the red close window
14.4 sec.,  5.2 sec., 4.2 sec., 4.3 sec.

Start times for Kepler 1.0.0.beta3
I ran "time ./kepler-1.0.0beta3.exe" and then clicked on the red close
window square in two windows.
52.0 sec., 22.0 sec, 18.7 sec., 19.1 sec.

The issue here is that Kepler instantiates all the actors so
that they are accessible to the search mechanism and Ptolemy does
not.  We talked about this in

The solution is to do lazy loading of Kepler actors or to have
a proxy or cache of the actor data that is searched.

I don't think the problem is reading the jars in as much as it
is instantiating the actors.  One thing to try would be to unjar all
the jars, create a single jar file (LoTR: one jar file rule them all)
and then index the jar file with jar -i.  Comparing the start times
between lots of jar files and the one jar file would be interesting.

I've found that running from jar files is faster than running from
class files because file system I/O for each .class is slow.



    Hi All,
        I did some kepler startup timing tests on a 3GHz Intel box. Under 
    Windows, I am getting about 75 sec for a 'cold' start and about 20 sec 
    for a 'warm' start (starting a second time). Startup is much faster 
    under Linux! (20/10 secs). Cold start using the installer version of 
    Kepler takes about 45 seconds on Windows. Note that removing all but one 
    of the actors had little effect on the long Windows cold start times.
        So I think our main problem is the long initial startup on Windows 
    machines. Unfortunately, most of our users are on Windows machines. And 
    the initial startup time is a turnoff for new users who are likely to 
    think that kepler is not loading and just quit.
        I think the real time consumer for 'cold' starts is the initial 
    reading of all the jar files. I think these are cached by the OS file 
    system, and that caching speeds up subsequent startups. Unfortunately, 
    if this is true, eliminating actors shipped with Kepler will have little 
    effect for most of our users, unless we can also drastically reduce the 
    number of jar files loaded at startup.
    Chad Berkley wrote:
    > I just ran it again after wiping .kepler and removing and rebuilding 
    > the kar library and I still get 20 sec.  I'm on Ubuntu 6.06 with java 
    > 1.5.0_10.  I'm measuring from the time that the ant output says 
    > "run-dev:" until the time a usable kepler window opens.
    > I just did the same test on my macbook pro (under osx) and it took 22 
    > seconds run-dev to kepler window.  Under windows on the mac (running 
    > in parallels, 512 MB RAM) it took 21 sec.  Kepler had never been run 
    > on the Parallels VM before.  After totally rebooting the mac, my 
    > startup time was 31 secs.
    > chad
    > Dan Higgins wrote:
    >> Chad,
    >>    Your startup times seem to be much faster than mine although our 
    >> machine configuratons seem the same! I am using Windows. Are you 
    >> using Linux?
    >>    If I use 'ant run-dev' on a 'cold' machine (i.e just turned on, 
    >> Kepler never executed) it just took ~90 seconds to see the kepler 
    >> screen appear. Shutting down and starting again took about 45 
    >> seconds. A third time took about 30 seconds. (All measured from 
    >> hitting the return after 'ant run-dev'). It's that first time that is 
    >> the real killer for new users. Are you really getting a 20 second 
    >> startup the first time?
    >> Dan
    >> Chad Berkley wrote:
    >>> I've been doing some messing around with timing various kepler 
    >>> activities.  The results are below.
    >>> Kepler tests on P4 3 GHz with 2 GB RAM
    >>> -------------------------------
    >>> Startup time with no actors in the kar directory: 10 sec
    >>> Startup time with all actors in the kar directory: 20 sec
    >>> Query time with remote search enabled and 329 components in the 
    >>> library (with NO local actors):  8 sec
    >>> Query time with remote search enabled and 329 components in the 
    >>> library (WITH local actors):  10 sec
    >>> Query time on http://library.kepler-project.org (same query): 1 sec.
    >>> Query time with remote search disabled (WITH local actors): < 1 sec
    >>> --------------------------------
    >>> One way to speed up our startup time (in fact, cut it in half) is to 
    >>> release a version of kepler with no actors pre-installed in the 
    >>> library and allow people just to use the components off the online 
    >>> repository (as we talked about in the last SEEK meeting).  It seems 
    >>> the only problem with this is that it slows down the search time for 
    >>> components.   I think the reason the search in Kepler is so much 
    >>> larger than just searching on the web site is that there is overhead 
    >>> with moving the data through the ecogrid interface.  There is also 
    >>> overhead in dynamically generating the results tree in kepler.  IMO, 
    >>> 8 seconds isn't too bad (it could be better) but we should probably 
    >>> put a status bar or something in there so people don't think its 
    >>> locked up.
    >>> thoughts?
    >>> chad
    >>> _______________________________________________
    >>> Kepler-dev mailing list
    >>> Kepler-dev at ecoinformatics.org
    >>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-de
    Dan Higgins                                  higgins at nceas.ucsb.edu
    http://www.nceas.ucsb.edu/    Ph: 805-893-5127
    National Center for Ecological Analysis and Synthesis (NCEAS) Marine Scienc
   e Building - Room 3405
    Santa Barbara, CA 93195
    Kepler-dev mailing list
    Kepler-dev at ecoinformatics.org

More information about the Kepler-dev mailing list