Re: performance.now in web workers

We discussed this item a few times and ended up deciding that it is a
good idea and we'll add it on our TODO list for future versions.

[[
atinder: Regarding bringing HRT to Web Workers, we have already
discussed that instead of just bringing the performance.now() property
to web workers, we are also interested in understanding what it'll mean
to move the entire performance property, including the Timing
interfaces, to web workers. Those changes will require additional
thought and should be covered in V2 of the timing specs. In addition,
there may be other web worker specific scenarios that we may be
interested in including in our next charter update, like performance of
spawning new worker threads. I recommend that instead of making a
one-off change now to move performance.now() to web workers, we consider
all the web worker changes we want to make in our next charter update
and in V2 of the specs.

Philippe: I agree.

Tony: I agree as well.
]]
http://lists.w3.org/Archives/Public/public-web-perf/2012Oct/0016.html


Philippe

On Sun, 2012-09-23 at 23:26 -0600, Chandler Prall wrote:
> As one of the headlining features about web workers is to use them for
> performance gains it makes sense to expose the sub-millisecond
> resolution `now` function to web workers. As has been discussed
> numerous times, Date.now is unreliable and inaccurate even at the
> millisecond resolution and these inaccuracies can have a strong impact
> on performance- and accuracy-sensitive applications.
> 
> 
> The `navigation` and `timing` properties on `window.performance` do
> not make sense in a worker context, so perhaps attaching the `now`
> function to a worker's `self` object is the most straightforward? I'm
> sure others will have better ideas for the API of this functionality.

Received on Thursday, 11 October 2012 15:00:34 UTC