W3C home > Mailing lists > Public > public-web-perf@w3.org > December 2016

Re: What does "navigationStart" mean as a second argument to performance.measure() in a web worker?

From: Philippe Le Hégaret <plh@w3.org>
Date: Thu, 15 Dec 2016 14:57:28 -0500
To: Boris Zbarsky <bzbarsky@mit.edu>, "public-web-perf@w3.org" <public-web-perf@w3.org>
Message-ID: <67e9f407-ddca-0e70-b6aa-6d2da326813e@w3.org>
On 12/15/2016 3:21 AM, Boris Zbarsky wrote:
> I guess we start in https://w3c.github.io/user-timing/ (which is
> helpfully not linked from <https://www.w3.org/TR/user-timing/>).  This
> says:
>   If startMark is omitted, let start time be 0. Otherwise let start
>   time be the value of the startTime attribute from the most recent
>   occurence PerformanceMark object in the performance entry buffer
>   whose name matches value startMark.
> Ignoring the missing "of" after "occurence" [sic; spelling], what does
> this actually mean?  How would a PerformanceMark object with such a name
> end up in the buffer?  Would it?

You cannot have a PerformanceMark using the "navigationStart" in 
non-Worker case. The spec says to throw a SyntaxError if you try to 
create one. It doesn't say that for Workers however and I don't think we 
should enable it.

> Following the link to
> https://w3c.github.io/user-timing/#dom-performancemark is a bit
> non-obvious, but it has a link to
> <https://w3c.github.io/performance-timeline/#dfn-performance-timeline>.

I guess we should link to how PerformanceMarks get created instead of 
the interface definition but that wouldn't be enough to address your issue.

> Incidentally, if I look at
> https://www.w3.org/TR/user-timing/#dom-performance-measure then it
> explicitly says, for the second argument:
>   May be the name of one of the attributes in the PerformanceTiming
>   interface [Navigation Timing]. In this case, the value of that
>   attribute is used as the start DOMHighResTimeStamp time value.

Yes and we "lost" it from the spec after we started to deprecate the 
PerformanceTiming interface. This was a mistake obviously. But, imho, we 
shouldn't include Workers from the behavior.

I need to make sure the spec takes this into account and allows cover 
the tests in:

> But this is all dating to back before Performance was exposed to
> workers.  In particular, PerformanceTiming is _not_ exposed to workers,
> so it's not clear how this should work in the worker world, exactly.

You're correct that this is not clear and I don't think we considered 
the case of Workers.

The goal is to deprecate PerformanceTiming overtime and we don't expose 
it to Workers on purpose. In addition, the "trick" of having predefined 
marks by reusing attribute names triggers a whole set of additional 
questions for future extensions that we'd rather avoid.

So, you asked what "navigationStart" means as a second argument to 
performance.measure() in a web worker. In this case, unless you did 
explicitly create a PerformanceMark object with that name, it would 
throw a SyntaxError... which isn't writing down in the spec.

> P.S. I'm still generally quite frustrated with the way the
> modularization of these specs was done and the resulting impossibility
> of actually tracking anything down in all the broken links and
> unexplained dependencies.  The primer was supposed to theoretically
> help, but in practice it's useless because it too has broken links.

The primer needs a refresh since we abandoned specs like FRAME-TIMING 
and SERVER-TIMING. Having said that, the first problem here is that I 
did cut off too much of the original User Timing specification, making 
the current draft unhelpful and broken.

Regarding the broken links, I've been unhappy for a while with the lack 
of proper linking system/tracker. We updated our specs to the new WebIDL 
syntax ... but we left that part out of the editor draft.

In summary, I need to raise a bunch of issues against the spec but feel 
free to beat me to it.

> Since in practice all these specs are having to be evolved in lockstep
> anyway because of interdependencies as far as I can tell, I strongly
> feel that they should just be a single spec.  That will at least make
> the interdependencies clear instead of hiding them.

I agree we have an interdependencies issue but this is not just limited 
to the perf specs imho. We link to a bunch of other specs as well and 
don't track those dependencies well. I've been meaning to explore 
whether some of the tooling used in the webrtc specs would help us on 
that front but reality didn't allow me to spend time on this front lately :(

Received on Thursday, 15 December 2016 19:57:38 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 15 December 2016 19:57:38 UTC