[kepler-dev] Kepler timing data

Dan Higgins higgins at nceas.ucsb.edu
Wed Feb 7 11:53:52 PST 2007


Christopher,
    I assume the first listed time is the 'cold' start. Note how much 
longer both Ptolemy and Kepler that subsequent times! (I agree that 
Kepler's loading of all the actors is an issue after that first time, 
but that first time is a real killer!)

Dan

Christopher Brooks wrote:
> Hi Dan,
>
> I'm swamped with other tasks, but this is all really interesting to
> me.
>
> 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
> square:
> 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
> http://bugzilla.ecoinformatics.org/show_bug.cgi?id=2346
>
> 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.
>
> _Christopher
>
> --------
>
>     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.
>     
>     Dan
>     
>     ---
>     
>     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
>    v 
>     >>>
>     >>>   
>     >>
>     >>
>     
>     
>     -- 
>     *******************************************************************
>     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
>     http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
> --------
>   


-- 
*******************************************************************
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 Science Building - Room 3405
Santa Barbara, CA 93195
*******************************************************************



More information about the Kepler-dev mailing list