Re: [Performance Timeline] Need higher resolution timers

On Mon, Aug 22, 2011 at 3:54 PM, Zhiheng Wang <zhihengw@google.com> wrote:

> On Mon, Aug 22, 2011 at 3:31 PM, James Simonsen <simonjam@chromium.org>wrote:
>
>> 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.
>>
>
>    Do you have a more specific example?
>
>
>> Down the road, as games and apps get more sophisticated, we can expect
>> people to want to time things within a frame.
>>
>
>    IIRC, 50 msec is the threshold for human to detect any latency at all in
> FPS games. An app can still measure some other ops
> inside it. But overall, I am still not sure why an application really cares
> to know the exact sub-millisecond delay.
>

It's not possible to know if an page is reaching 60FPS (or 24fps for video
or most other framerates) or not without submillisecond precision.

It's also not really possible to do accurate tracing of user code with only
millisecond precision, which is one of the proposed use cases for User
Timing.

- James



> cheers,
> Zhiheng
>
>
>>
>> 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.
>>
>> James
>>
>
>