[kepler-dev] Kepler timing data
Christopher Brooks
cxh at eecs.berkeley.edu
Wed Feb 7 13:43:41 PST 2007
Yes, the first time is the cold start, where the JVM is getting
read from disk and then the app is getting read from disk.
The second and subsequent times are when the JVM and app are
presumably in memory.
Note that the Kepler times are slightly inflated because I
had to close two windows, not just one. That said, I would
say that Kepler is 4x - 5x slower to open than Ptolemy.
I'm all for helping you solve this problem, but I'm fairly certain the
solution was put off into post Kepler-1.0.
_Christopher
--------
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 se
c
> 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 Window
s
> machines. Unfortunately, most of our users are on Windows machines. A
nd
> 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 lit
tle
> effect for most of our users, unless we can also drastically reduce t
he
> number of jar files loaded at startup.
>
> Dan
>
> ---
>
> Chad Berkley wrote:
> > I just ran it again after wiping .kepler and removing and rebuildin
g
> > the kar library and I still get 20 sec. I'm on Ubuntu 6.06 with ja
va
> > 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 (runnin
g
> > in parallels, 512 MB RAM) it took 21 sec. Kepler had never been ru
n
> > 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 ou
r
> >> 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 s
ec.
> >>>
> >>> Query time with remote search disabled (WITH local actors): < 1 s
ec
> >>> --------------------------------
> >>>
> >>> 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 onlin
e
> >>> repository (as we talked about in the last SEEK meeting). It see
ms
> >>> 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 overh
ead
> >>> with moving the data through the ecogrid interface. There is als
o
> >>> overhead in dynamically generating the results tree in kepler. I
MO,
> >>> 8 seconds isn't too bad (it could be better) but we should probab
ly
> >>> 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/kep
ler-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 Scienc
e Building - Room 3405
Santa Barbara, CA 93195
*******************************************************************
--------
More information about the Kepler-dev
mailing list