Re: Firefox and User Timing API in workers

On Thu, May 28, 2015 at 3:33 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> 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.


As Jonas outlined, there are valid use cases for doing time accounting
against both the parents timebase and own start time. As such, I think
you'd have to provide *some* branching logic when you're running within a
worker.. That said, the distinction between dedicated vs shared seems
redundant, at least as far as time accounting is concerned. This is why we
proposed changing the current definition of dedicated worker's time-origin
to be consistent with shared worker's. Concretely, what we have now is:

- Time origin is always relative to current context: start of navigation,
or time of creation of current worker context [1].
- workerStart reports the difference between time origin of worker and time
origin of context that started it [2].

As a result, if you do nothing, all of your timestamps will report times
relative to current context. However, if you want to do accounting relative
to parent's context, you'd just query workerStart and add it's value to
your local timestamps... and you can check if workerStart is non-zero to
know if there is a parent context. I think this provides the most
consistent API across all the cases, regardless of worker type and how/who
started it.

Is that coherent? :-)

ig

[2] http://w3c.github.io/hr-time/#sec-time-origin
[3] http://w3c.github.io/hr-time/#sec-worker-start

On Thu, May 28, 2015 at 3:33 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> 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
>
>