[kepler-dev] Kepler timing data

Chad Berkley berkley at nceas.ucsb.edu
Tue Feb 6 10:12:50 PST 2007

Yeah, i was doing initial startup time, which is reduced after the cache 
gets built so the time for all of the actors in the library would be 
slightly lower on subsequent startups.

For the airplane problem, I've kind of come up with a solution to that 
(kind of a hack at this point).  Basically all of the actual class files 
are still distributed with kepler.  Right now the actor that is on the 
server is just moml, no class file.  So when you do a search, the moml 
gets downloaded and cached then is put in your local tree after the 
initial download.  So basically, as long as you search for and drag out 
any actor that you might need BEFORE you board the aircraft with your 
$10 T-mobile airport internet connection, you're good to go :)  An idea 
I had but haven't implemented is to allow you to download a whole 
subtree of actors at the same time which would allow you to, say, grab 
all of the R actors or whatever.

In my talk on monday, I'll talk a bit about dynamic class loading and 
how we hope that will make it possible to have the classes on the server 
along with the moml so that we won't have to distribute the class files 
with kepler.  It kind of defeats the overall purpose of the repository, 
although I still think its useful at this point.

As for ptolemy startup time, i haven't timed that at all.  I'll see if I 
can remember how to build ptII outside of kepler and give it a try :)


Christopher Brooks wrote:
> Hi Chad,
> It sounds like you have a possible solution in having no actors.
> However, this means that Kepler would not work on the airplane etc.
> Would it be possible to have a fallback to using the kar directory
> if the search did not work?  I like the idea of a status bar.
> I'd be interested to see how the start up time of Ptolemy compares on
> your setup.  The Ptolemy vs. Kepler startup time is a somewhat
> orthogonal to the search problem, but it might really reduce your
> startup time overall.
> Also, are you doing one start up, throwing away the timing data
> and then measuring three successive startups?  I know that for me
> the first start can be slow.
> Don't forget: "There are lies, damn lies and statistics" :-)
> _Christopher
> --------
>     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-dev
> --------

More information about the Kepler-dev mailing list