W3C home > Mailing lists > Public > public-web-perf@w3.org > October 2010

RE: [Web Timing] UserTiming

From: Anderson Quach <aquach@microsoft.com>
Date: Thu, 7 Oct 2010 01:57:44 +0000
To: Tony Gentilcore <tonyg@google.com>
CC: "public-web-perf@w3.org" <public-web-perf@w3.org>
Message-ID: <1E1FF4102DEA7A40AF9CC342044ECE5D2E20703D@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com>
Thanks for the feedback.  

#1, Actually, the intention is that either getMark("fullyLoaded") or timing.fullyLoaded would be able to retrieve the timestamp for fully loaded and markFullyLoaded and mark("fullyLoaded") would mark the same marker. I'll be more clear on this in the spec.

I'll change the naming it to setFullyLoaded(), that makes sense.

#2 This is an interesting idea, having a map that is accessible under timing. I don't want to cause confusion when serializing the navigation timing markers when it's accompanied by a ton of user markers as set by an overzealous developer. I'll have to think about this a little further.

#3 The intention for returning a list is for highly repetitive patterns like loops and etc. That way marks are coalesced under a single key. Let me think about the implications for returning a list in getMark();

Comments:
#1 This has been captured in a recent update of the spec [1].

#2 Currently in the IE platform preview it's implemented in the .performance namespace. I'll update the interface definition to reflect  [Supplemental] interface Performance.

#3 Fixed [1]

#4 In the IE platform preview and beta, in IE9 standards mode we support the ES5 compatible way of determining the instance object's prototype. That is calling Object.PrototypeOf(object); you can see it returns the following in the dev toolbar.

[object MSPerformancePrototype] {
	navigation : ,
	timing : ,
                ...
}

[1] http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/UserTiming/Overview.html 



-----Original Message-----
From: Tony Gentilcore [mailto:tonyg@google.com] 
Sent: Monday, October 04, 2010 10:38 AM
To: Anderson Quach
Cc: public-web-perf@w3.org
Subject: Re: [Web Timing] UserTiming

Looks great to me! I'm excited to see this happen.

Some high level thoughts:
1. If a user calls mark("fullyLoaded"), they can later retrieve that with getMark("fullyLoaded"), but if they call markFullyLoaded(), they have to retrieve it with timing.fullyLoaded. This somehow doesn't seem intuitive to me. I don't have a great proposal, but some ideas:
  - Call it setFullyLoaded() to set it appart from the others.
  - Move markFullyLoaded() into timing.
  - Cause it to both set timing.fullyLoaded and add a mark that is retrieve via getMarks().
2. For phoning home, a page will have to serialize both performance.timing and performance.getMarks(). Perhaps we could solve
#2 and make the whole thing easier to use by exposing a map of marks under timing right along with the built-in marks. For instance:
  timing {
    navigationStart : 123,
    fetchStart : 123,
    ...
    marks : {
      userMarkA : 123,
      userMarkB : 123
    }
  }
3. Something feels odd about the fact that I can call mark("foo") multiple times and have multiple entries show up in getMarks(), but if I call getMark("foo"), I only get a single number instead of a list.
My recommendation is to only return the most recent time per key in getMarks(). But if we think it is a valuable feature to allow multiple times per key, then getMark() needs to return a list.

And a few comments/questions on trivial details:
1. It looks like in the IE9 implementation getMarks() can be called with no arguments to retrieve all marks, but I don't see that in the spec.
2. Which namespace does this fall under? I assume window.performance based on the IE9 beta implementation. If so, the spec should say "[Supplemental] interface Performance" instead of "interface UserTiming".
3. Typo: two interfaces are named DOMPerformanceTimingList, the second looks like it should be DOMPerformanceTiming.
4. I'd like to reconsider the interface names as a whole to get a consistent scheme. IE doesn't expose __proto__, but other user agents do. Right now we have Performance, NavigationTiming, NavigationInfo (from Navigation Timing spec) and UserTiming, DOMPerformanceTiming, DOMPerformanceTimingList (from User Timing spec). While this isn't what WebKit currently implements, this might be a good scheme:
DOMPerformance, DOMPerformanceTiming, DOMPerformanceNavigation, DOMPerformanceMark, DOMPerformanceMarkList. But I'm open to any scheme that is internally consistent.

-Tony

On Fri, Oct 1, 2010 at 8:07 PM, Anderson Quach <aquach@microsoft.com> wrote:
> Hi All,
>
>
>
> I've added the first draft copy of the UserTiming [1] spec to webperf 
> repository.  The problem with using new Date() to capture timing 
> information for custom scenarios relies on the accuracy of the timer 
> within the user agent.
>
>
>
> Building on the 1ms precision called out in Navigation Timing,  this 
> specification defines an interface for web applications to capture 
> timing information with a developer supplied name. The user agent 
> captures the time stamp at the point and time specified in the code 
> executing in the user agent.
>
>
>
> [1] 
> http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/UserTiming/Overview.h
> tm
>
>
>
> Regards,
>
> Anderson Quach
> IE Program Manager
Received on Thursday, 7 October 2010 01:58:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 21 December 2010 18:13:55 GMT