[kepler-dev] [Bug 4764] slow performance after run

[bugzilla-daemon at ecoinformatics.org]

http://bugzilla.ecoinformatics.org/show_bug.cgi?id=4764

--- Comment #1 from Oliver Soong <soong at nceas.ucsb.edu> 2010-02-11 12:12:11 PST ---
I profiled Kepler comparing an execution and an execution followed by a
parameter change.  First, I loaded tpc09 into a local repository and pre-cached
all the data.  I then restarted Kepler with profiling on, opened tpc09 from the
repository, ran it, then closed Kepler.  The restsarted Kepler again with
profiling on, opened tpc09 again, ran it, changed a parameter, and closed it
again.  A couple of things jump out.

First, >50% of all processing is driven by
java.net.SocketInputStream.socketRead0: 
    java.net.SocketInputStream.socketRead0(SocketInputStream.java:Unknown line)
    java.net.SocketInputStream.read(SocketInputStream.java:129)
    java.net.SocketInputStream.read(SocketInputStream.java:182)
    java.io.DataInputStream.readInt(DataInputStream.java:370)
    org.hsqldb.Result.read(<Unknown Source>:Unknown line)
    org.hsqldb.ServerConnection.run(<Unknown Source>:Unknown line)
    java.lang.Thread.run(Thread.java:619)

Second, the count for this call is nearly doubled when changing the parameter
(78137 to 139903).

Since a lot of stuff relies on hsqldb, the high percentage may not be too
surprising.  However, the doubled count is why the program runs slow.

So far, this is triggered by an execution, seems to scale with workflow size,
and involves something that makes calls to the hsqldb.

I'll attach the hprof data.

-- 
Configure bugmail: http://bugzilla.ecoinformatics.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.