Re: Firefox and User Timing API in workers

On Wed, May 27, 2015 at 5:56 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 5/27/15 6:01 PM, Ilya Grigorik wrote:
>>
>> That's what I meant to say.. Single attribute that works across all
>> worker cases :)
>
> And I'm saying I'd prefer a single attribute that works across all globals
> period and represents the zero time of the monotonic clock in that global,
> so people don't have to branch their code on whether they're in a worker or
> not.

Note that for dedicated Workers there are two reasonable "zero times".

A dedicated Worker is essentially an extra thread allowing you to do
heavy work from a webpage. So many times it likely is useful to
measure the "zero time" inside a dedicated worker as the same as the
"zero time" of the page that instantiated the worker.

Consider for example a webpage that lazily spins up one or more
workers and hands work items to whichever worker is available to
process the given task. In this case the start time of the worker is
irrelevant and what you want to track is when a task happens in
relation to page start.

In short, dedicated workers are often just like a JS library that's
running in a page. It just happens that the library runs on a separate
OS thread in order to not disrupt UI.

Other times a dedicated worker might perform work as part of the
processing that it does when the worker first loads. Here it might be
more interesting to measure time against when the worker started to
load, rather than when the page that created the worker started to
load.

Shared Workers and Service Workers seem more like normal pages and
what you're generally interested in is measuring time compared to when
the worker started to load rather than when an individual page started
to load.

Also note that in spec Shared Workers (and I hope Service Workers) can
create dedicated workers. In which case the dedicated worker is a
workhorse for the shared/service worker and so measuring time against
the parent worker is what's interesting.


But I generally agree with Boris that having properties (and APIs in
general) that work across all globals are preferable than just
creating consistency for the various types of workers that exist.

I'm just arguing that we might need to have two properties rather than
one here. But I see no reason we couldn't make those two exist in all
globals.

/ Jonas

Received on Thursday, 28 May 2015 22:34:32 UTC