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; On 2011/02/03 23:12:13, jbrosenberg wrote:
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.
The basetime is used to establish the start of the timline in speedtracer. WebKit gives us system relative time, and so the first top level event gets a synthesized base time that is subtracted from all subsequent timing information. So, your baseTime should definitely be TimeKeeper specific. 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())); On 2011/02/03 23:12:13, jbrosenberg wrote:
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.
Basically there are a few points in speedtracer land where we binary search through data which breaks down with parallel events. If you run a debug build of speedtracer on your data, there will be an error message logged if we detect that the data isn't ordered as we expect. Although, I think parallel top level events might be shielded from most of this. http://gwt-code-reviews.appspot.com/1336803/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
