[minutes] 20110126 Web Performance WG

Web Performance Working Group
26 Jan 2011

See also: IRC log<http://www.w3.org/2011/01/26-webperf-irc>

Minutes
http://www.w3.org/2011/01/26-webperf-minutes.html
Attendees
Present
Plh, +1.650.214.aaaa, [Microsoft], +1.650.253.aabb, Ronald, +1.415.829.aacc, AndersonQuach, TonyG, plh, NicJansma, Zhiheng, KyleSimpson, ArvindJain, JasonSobel
Regrets
Chair
ArvindJain
Scribe
AndersonQuach
Contents

  *   Topics<http://www.w3.org/2011/01/26-webperf-minutes.html#agenda>
1.     Feedback on User Timing updates<http://www.w3.org/2011/01/26-webperf-minutes.html#item01>
2.     Summary<http://www.w3.org/2011/01/26-webperf-minutes.html#item02>

*         i. In the coming meeting let's prepare to review the next waves of tests for Navigation Timing. Tony will update the his tests to use the test harness and Anderson will submit additional Navigation Timing tests.

*         ii. Let's send feedback about User Timing offline.

________________________________

list the agenda

<scribe> scribe: AndersonQuach

<plh> https://dvcs.w3.org/hg/webapps/file/tip/tests/XMLHttpRequest

<plh> http://w3c-test.org/

http://lists.w3.org/Archives/Public/public-html-testsuite/2011Jan/0016.html
Feedback on User Timing updates

TonyG: Update the Google submitted with the common test harness.
... I have about seven more with PHP.

NicJansma: We have tests that do simple ordering, attribute existence and enumerations.

TonyG: We have a test for the page cache.

NicJansma: Do you mean a cached document navigation.

TonyG: Firefox calls it fastback. We have a page show and page hide and not unload event. And need to be careful that the numbers won't get reset.

<plh> btw, the Call for Review for the Web Performance IG charter is ending at the end of the week. Make sure your company answered it!

TonyG: To make sure cross-origin domain constraints is satisfied.

NicJansma: Can we get SSL support?

plh: When do you need it?

AndersonQuach: Sooner the better.

Zhiheng: We need to look at the ability to meet the normative requirements for the tests.

NicJansma: Let's take a step back after the two submissions and review the gaps.

move to agenda 2

Zhiheng: The data structure moved to PerformanceTiming for ease of JSON.stringify. And the additionof measures.

NicJansma: Concerned with the ease of stringify only the navigation timing interface separate from user timings.

Zhiheng: That's a good point.

NicJansma: Unless there is some way to filter out sub attributes.

https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/UserTiming/Overview.html

<getify> ok i'm here

<plh> https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/UserTiming/Overview.html

<getify> so, we're looking at the PerformanceUserTiming interface correct?

AndersonQuach: bubbling up what do we want the default experience to serialize be, to stringify the timing interface only gets Navigation timing.
... @getify, yes PerformanceTiming

NicJansma: Keeping user attribute at the performance namespace, to help users to get specific parts of the performance interface. we only have APIs off of users. Right now it's designed to stringify the result of the GetMarks or GetMeasures.
... The concern is if we add it to the timing attribute, it can grown unbounded and sending back a large payload that they may not expect or be able to handle.

Zhiheng: The change can be an indexable attribute called user. We can it under performance.userTiming and it be indexable datastructure.

NicJansma: before there were GetMarks, that was changed to the getter PerformanceMark

Zhiheng: Just to make the interface cleaner.
... We can get individual attributes or the entire data structure.
... Measure, name of the measure, reference point of the measure and the time between the reference point and current time.
... Measure is more comprehensive, name, epoch time of captured and the delta from the reference point.
... and end time.

AndersonQuach: When thinking about measure we thought about: 1. optimization for capturing deltas 2. the ability to retroactively construct a waterfall timeline.

KyleSimpson: I understand it calculates the delta. The API was not initially self explanitory.

Zhiheng: Thanks for the feedback, I want to make the interface more explicit.

TonyG: Why do we want to pass in the time?

Zhiheng: Possible to get different ending time in JavaScript, calling measure consecutive, and take the JavaScript date to pass into measure.

TonyG: Mark and Measure we're populating string, number pairs in an array we hang somewhere.
... if you're picking your own number and string, what's the value add?

Zhiheng: That's a good question, that should go towards this framework. We can do this in JavaScript.

TonyG: The one bit of ease of use, a mark method that takes the name to use the high performance timer, to get custom marks and built in marks. Beyond that is duplicating functionality that can be done in JS.

Zhiheng: How does this align with Nav Timing.

TonyG: it would be an array, currently named user, but maybe timing.marks, it's an array with a string and a number.
... This could be just to expose a number, get high performance counter.
... this isn't providing much utility beyond user arrays.

Zhiheng: I'm all for having the high preceision counter.

KyleSimpson: Is name supposed to be unique?

AndersonQuach: Originally it was for an associative array, e.g. myaction can be marked n times.the name to timestamp mapping was one to many.

NicJansma: We had in the getters the ability to get a single indexed time or by name or all the timings.

<AndersonQuach_> set logs world-visible

<AndersonQuach_> generate minutes

<AndersonQuach_> rrsagent generate minutes
Summary

<AndersonQuach_> i. In the coming meeting let's prepare to review the next waves of tests for Navigation Timing. Tony will update the his tests to use the testharness and Anderson will submit additional Navigation Timing tests.

<AndersonQuach_> ii. Let's send feedback about User Timing offline.