W3C home > Mailing lists > Public > public-web-perf@w3.org > September 2013

Re: [HighResTime] Web Worker support

From: Ben Vanik <benvanik@google.com>
Date: Wed, 11 Sep 2013 18:31:23 -0700
Message-ID: <CAOB_hFRTHk-PZjhkYZE7r18re8gD5abb-7D7oScSxFq3HZpJbA@mail.gmail.com>
To: James Simonsen <simonjam@google.com>
Cc: Jatinder Mann <jmann@microsoft.com>, "public-web-perf@w3.org" <public-web-perf@w3.org>
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 ****
>>
>>  ** **
>>
>
>
Received on Thursday, 12 September 2013 01:32:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:01:21 UTC