[kepler-dev] Kepler timing data

[Christopher Brooks]

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
--------