RE: [Performance Timeline] Need higher resolution timers

As an added bonus, having all timestamps based on the beginning of the navigation of the root document (navigationStart) makes it easier to visually parse timestamps, since everything is 0-based instead of current Unix-epoch-time based.

Before, looking at a ResourceTiming entry that started 100ms after navigationStart (@ 1314223489090 epoch):
startTime:   1314223489190
responseEnd: 1314223489193

After switching to navigationStart-based sub-millisecond timestamps, it's easier to quickly see that this resource was requested 100ms into the navigation and took a total of 20ms, instead of trying to mentally do math with 13-digit numbers.
startTime:   100.000
responseEnd: 120.000

I'd call that a usability win.

- Nic

From: public-web-perf-request@w3.org [mailto:public-web-perf-request@w3.org] On Behalf Of James Robinson
Sent: Wednesday, August 24, 2011 2:48 PM
To: Jatinder Mann
Cc: James Simonsen; public-web-perf; Zhiheng Wang
Subject: Re: [Performance Timeline] Need higher resolution timers


On Wed, Aug 24, 2011 at 2:41 PM, Jatinder Mann <jmann@microsoft.com<mailto:jmann@microsoft.com>> wrote:

Based on the thread comments, our decision to use a monotonic clock was partly driven by not wanting the timestamps to be compared with Date.now(), which is subject to system clock changes, so my originally concern here is not an issue.



Per the WG discussion today, we are proposing that all timing attributes returned from the new getEntries() methods be defined in sub-millisecond resolution in terms of a monotonic clock measuring time elapsed from the beginning of the navigation of the root document (navigationStart). In order to preserve compatibility of performance.timing (Navigation Timing), getting timing attributes directly from performance.timing will continue to return millisecond resolution from the Unix epoch. Does anyone see a concern with this approach?



Likewise, would requestAnimationFrame timestamp also use this new timebase?

I think that we want to do this as well - I was going to send out a proposal for exactly this once we reached consensus on this thread (which it seems like we have).  Excellent!

- James



Jatinder