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/04 03:21:52, jbrosenberg wrote:
will do....although, it looks like it doesn't seem to really need the
baseTime
afterall? I tried commenting out the generation of the baseTime data altogether, and it doesn't seem to affect things at all (speedtracer
seems to
normalize the time just fine). That and also for the case of
processCpuTime
(which has no basis in wall time)...
Done. 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())); Yeah, what I am seeing is that the summaries can't be separated for individual timelines that overlap...You can only get a summary for a particular duration of time, and overlapping timelines will all contribute. I think this is fine and desired behavior....The speed tracer interface doesn't currently allow for separating things out otherwise...You can click on individual events, and the total time/self-time for that event appear accurate however, so I think it's been good....no? Longer term, I'd have thought that making speedtracer support parallel timelines would be a goal anyway, no? http://gwt-code-reviews.appspot.com/1336803/diff/3002/4006#newcode313 dev/core/src/com/google/gwt/dev/util/log/speedtracer/SpeedTracerLogger.java:313: * Thread that converts log requests to JSON in the background. Well, not quite. The System.nanoTime() is always increasing faster than the currentThreadCpuTime(), since current thread cpu time will take pauses during i/o waits, or when the thread is swapped out of context. What's happening here is that each time you reset, you are setting your offset to match the current wall time elapsed for the process. This way, there's a semblance of chronological ordering in the output. The time between events isn't accurate, but the duration of individual events is preserved according to thread cpu time. http://gwt-code-reviews.appspot.com/1336803/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
