W3C home > Mailing lists > Public > public-web-perf@w3.org > August 2011

[Performance Timeline] Need higher resolution timers

From: James Simonsen <simonjam@chromium.org>
Date: Mon, 22 Aug 2011 15:31:07 -0700
Message-ID: <CAPVJQi=A5ru9H40KZTnh_=6EYv5eRaEAPgmu5Q5oJBGuN-DmZg@mail.gmail.com>
To: public-web-perf <public-web-perf@w3.org>
Hi web-perf,

So far, we've spec'd the Performance Timeline to use 64-bit ints of
milliseconds. This has mostly been so that the times look like Date.now().
It's also sufficient for network timing.

However, looking longer term, there's a need for more precision. One example
is graphics, where milliseconds are already insufficient for measuring frame
rate. Down the road, as games and apps get more sophisticated, we can expect
people to want to time things within a frame.

Switching to a double seems like the easiest solution to adding more
resolution. However, I'm a bit worried we're running out of bits. Date.now()
returns milliseconds since 1970 and we're currently spec'd to use the same
offset. If we switch to double, we've already consumed 40 of the 52 bits
available just measuring milliseconds since 1970. Getting to microsecond
resolution leaves us with only 2 spare bits. That seems a bit tight.

If we throw out that 1970 offset, we can get much higher resolution times. I
propose we just measure time since initial root document navigation (and
hope nobody leaves the same page open for 40 years). It could be stored as a
double of milliseconds.

Received on Monday, 22 August 2011 22:31:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:31 UTC