RE: [HighResTime] Web Worker support

We were thinking about introducing a performance.originTime, which would define the time value from which performance.now() is measured. For a dedicated worker or a document the origin time is the start of page navigation of that document, and for a shared worker the origin time is when the shared worker is created. The originTime attribute would describe that origin time relative to a reference point in time before the start of navigation of the document, e.g., unix epoch or start of browser launch.

Suppose I have a shared worker A that was created 10ms after the start of navigation of the parent document. If I call performance.now() 5ms after the shared worker A was created in both the worker and the parent context, I should see the following values:

Shared worker A:
performance.now(): 5.000 ms

Parent context:
performance.now(): 15.000 ms


If we introduce a performance.originTime that describes the time relative to unix epoch, I may get something like so:

Shared worker A:
performance.now(): 5.000 ms
performance.originTime: 1378924562563.000 ms
performance.originTime + performance.now(): 1378924562568.000 ms

Parent context:
performance.now(): 15.000 ms
performance.originTime: 1378924562553.000 ms
performance.originTime + performance.now(): 1378924562568.000 ms

Adding originTime to the performance.now(), gives you a time value that is comparable in either context. This assumes that we have enough bits in a double to describe time since Jan 01 1970 in milliseconds in microsecond resolution.

Alternatively, we can define the origin for originTime to be the launch of the browser. Assuming the parent context was created 100ms after the launch of the browser, we would get something like so:

Shared worker A:
performance.now(): 5.000 ms
performance.originTime: 110.000 ms
performance.originTime + performance.now(): 115.000 ms

Parent context:
performance.now(): 15.000 ms
performance.originTime: 100.000 ms
performance.originTime + performance.now(): 115.000 ms

Not using unix epoch has the benefit that developers won't mistakenly compare this time with Date.now(), which isn't monotonically increasing and can be changed.

Any thoughts on this approach?

Jatinder

From: Ben Vanik [mailto:benvanik@google.com]
Sent: Tuesday, September 10, 2013 8:59 PM
To: Jatinder Mann
Cc: James Simonsen; public-web-perf
Subject: Re: [HighResTime] Web Worker support

Our use cases require comparing times from workers with their parent page context, but if that's possible to do with a delta of load time of the different contexts (performance.timing.navigationStart in the page and performance.whatever in the worker) instead of having now() values line up that's fine.

On Tue, Sep 10, 2013 at 4:09 PM, Jatinder Mann <jmann@microsoft.com<mailto:jmann@microsoft.com>> wrote:
Let's discuss performance.originTime in this week's call. We had raised the idea of possibly defining the origin time, so that time values obtained from a shared worker context could be compared with a dedicated worker or the top level browsing context. Not sure how common it will be to compare time values from different contexts, but it's worth discussing.

Thanks,
Jatinder

From: James Simonsen [mailto:simonjam@chromium.org<mailto:simonjam@chromium.org>]
Sent: Wednesday, September 4, 2013 1:35 PM
To: public-web-perf

Subject: Re: [HighResTime] Web Worker support

On Tue, May 14, 2013 at 11:20 AM, James Simonsen <simonjam@chromium.org<mailto:simonjam@chromium.org>> wrote:
Sorry for being late getting back to this thread...

On Thu, Apr 18, 2013 at 10:44 AM, Jatinder Mann <jmann@microsoft.com<mailto:jmann@microsoft.com>> wrote:
Ben,

If you're just looking at deltas, differences between two time values, the origin shouldn't matter. Is there a case where deltas wouldn't be good enough and you would want the absolute numbers?

If we were are to provide the origin time as a separate value (e.g., performance.originTime), it would need to be in the same sub-millisecond resolution in order to be comparable with other DOMHighResTimeStamps; the spec currently suggests one thousandth of a millisecond. Double precision may be able to support that for milliseconds since Unix epoch.

I don't fully understand the originTime. Is this effectively a global monotonic clock across all processes (workers and tabs)?

Ping? Are we going to do anything about this?

James