Christopher, I saw a commit you made to ptolemy.kernel.util.NamedObj, specificially r1.303 where you reimplemented the ContainedObjectsIterator to no longer use lazy initialization. I have seen no ill effects of this change. However, I did notice something else. Since the lazy initialization has been removed, it is much more obvious what ContainedObjectsIterator really is - nothing more than a wrapper class around Iterator. When profiling (I'm giving yourkit.com profiler a try - don't like it much) I saw that Object.<init>() was a pretty significant time consumer. Object.<init>() was being called for each instantiation of new ContainedObjectsIterator(). After making, NamedObj.containedObjectIterator() simply return attributeList().iterator(), the time consumption of Object.<init>() was reduced by 50%.
If you find no bad effects of removing the lazy initialization, then I suggest you completely drop the ContainedObjectsIterator helper class, and implement the containedObjectsIterator() in the more simple manner. It both reduces code and increases performace. Kevin Christopher Brooks wrote: >Hi Kevin, >Thanks for the analysis! > >I'll see about replicating your results and tuning the Ptolemy code. >I'll see what I can do soonish, this week or next. > >_Christopher > > >-------- > > 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] >-------- > > ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: [EMAIL PROTECTED]
