Hi all,
I ran the Kepler startup through a performance monitoring tool the other
day and learned some things which I would like to pass along.
I used the TPTP system in Eclipse to measure the performance. This is
an amazing tool and I suggest you check it out sometime. Since I'm a
rookie with this tool, and don't really know too much about the ptolemy
startup my observations and assessments might be completely off base.
I enabled monitoring in all non-java.* packages and hence ended up with
performance metrics in the ptolemy code as well as the kepler code.
TPTP reports wall-clock time which is completely skewed because the
application runs much more slowly when being monitored. However, it
does allow you to convert absolute time into percentage of total time so
I'll report those numbers here when appropriate.
There were 4 places in the ptolemy code which were pretty significant.
1) ptolemy.data.type.TypeLattice$TheTypeLattice.<cinit> in the call to
_basicLattice.isLattice(). The profiler says this is about 10% of the
startup time. Since the _basicLattice is constructed by compiled in
statements, you should only have to verify that changes in the source
result in a valid lattice. What I mean is, this particular test needs
only be performed once each time you update TheTypeLattice and does not
need to be performed with each application startup. I suggest you
replace the test with an assert like this:
assert _basicLattice.isLattice() : "TheTypeLattice: The type
hierarchy is not a lattice";
Then you can have a unit test run during compile or other times which
turns on this assertion to verify proper changes to the code.
2) NamedObject$ContainedObjectsIterator.hasNext() is called many times.
I noticed you are using some lazy evaluation of _attributeListIterator
in the methods for this inner object. Instead of doing lazy evaluation
perhaps you could change it to initialize this variable in the
constructor. Then the tests would not be needed in the other methods.
Of course this does change the semantics of the Iterator, and I cannot
determine if such a change would break usage of the iterator.
3) The FloydWarshallStrategy is called 2 times and accounts for 8% of
startup time. I don't really know where this is being called.
4) By far the largest consumer is the XmlParser class in
com.microstar.xml. It's base time is 37% of startup. (Base time is
amount of time spent executing code in the class itself, does not
include time spend in function calls). Of these it looks like the
TryRead and readLiteral methods are pretty intensive.
Kevin
----------------------------------------------------------------------------
Posted to the ptolemy-hackers mailing list. Please send administrative
mail for this list to: [EMAIL PROTECTED]
