http://gwt-code-reviews.appspot.com/1336803/diff/1/3 File dev/core/src/com/google/gwt/dev/util/log/speedtracer/SpeedTracerLogger.java (right):
http://gwt-code-reviews.appspot.com/1336803/diff/1/3#newcode477 dev/core/src/com/google/gwt/dev/util/log/speedtracer/SpeedTracerLogger.java:477: private final long zeroTimeMilliseconds; Yeah, I really didn't change the behavior of this, perhaps it should be based off the current timeKeeper implementation? It seems to be used as an added "baseTime" value added to parent events. It looks like in the case of the ProcessNormalizedTimeKeeper implementation, at least, this may not align properly with the scale of the process time logging (which doesn't really use system time at all). So far, I haven't noticed anything askew in the results so far, but I'd be interested to understand the purpose of the baseTime better, and I can change this to be supported by the timeKeeper class instead. http://gwt-code-reviews.appspot.com/1336803/diff/1/3#newcode592 dev/core/src/com/google/gwt/dev/util/log/speedtracer/SpeedTracerLogger.java:592: "Cummulative Collection Count", Long.toString(gcMXBean.getCollectionCount())); Yes it is a parallel timeline (which represents the gc happening in a separate thread), but in practice this actually produces nice output, with the GC events as separate waterfalls aligned and above the main event they correspond to. The totals do appear to be accurate, but you have to take it for what it is (e.g. GC took 25% of the total time logged). If you want, I can send you some sample generated output, if you would like to sanity check it. http://gwt-code-reviews.appspot.com/1336803/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
