- From: Ilya Grigorik <igrigorik@google.com>
- Date: Fri, 29 May 2015 08:09:32 -0700
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Boris Zbarsky <bzbarsky@mit.edu>, "public-web-perf@w3.org" <public-web-perf@w3.org>
- Message-ID: <CADXXVKpMqzr36eg-SK0pindGWUpbn95N8OtV27QaQi5MNfv9Uw@mail.gmail.com>
Boris, Jonas, thanks.. owe you a reply on both of those once this I/O thing has blown over :) In the meantime, would either of you guys be able to join next week's conf call -- Jun 3rd, 12PM PST? In addition to what we're discussing in this thread, I'd love to hear your thoughts and feedback on FT + :visited [1], and attribute filtering [2]. [1] https://github.com/w3c/frame-timing/issues/40 [2] https://github.com/w3c/performance-timeline/pull/11 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 > >
Received on Friday, 29 May 2015 15:10:42 UTC