Re: [HighResTime] Web Worker support

This looks good Jatinder.

One thing I've noticed with navigationStart while trying to get accurate
system timings is that it's 1ms resolution. This makes it hard to correlate
(start+now()) with a real system time obtained through other means (such as
from other browser APIs or system tools).
I actually have some code that (very nastily) tries to get the real time (
https://github.com/google/tracing-framework/blob/master/src/wtf/wtf.js#L86),
but it'd be nice if this new 'originTime' could return fractional values
and avoid the need to do this.



On Wed, Sep 11, 2013 at 6:25 PM, James Simonsen <simonjam@google.com> wrote:

> Definitely on board for this.
>
> originTime might not be the best name, because "origin" already has
> meaning on the web. Maybe monotonicClockOffset?
>
> I'm fine with browser start time or something similar for the reference.
> Maybe we even just leave it undefined with a suggestion that implementers
> pick something like startup time. I'd hate to have to define "browser
> startup." We should just specify it needs to be a fixed point for the
> entire browsing session.
>
> James
>
>
> On Wed, Sep 11, 2013 at 11:45 AM, Jatinder Mann <jmann@microsoft.com>wrote:
>
>>  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>
>> 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]
>> *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>
>> wrote:****
>>
>>  Sorry for being late getting back to this thread...****
>>
>>  ****
>>
>> On Thu, Apr 18, 2013 at 10:44 AM, Jatinder Mann <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 ****
>>
>>  ** **
>>
>
>