RE: [User Timing] Integration with Performance Timeline

When we had first discussed using a unified model of retrieving performance entries, we had agreed that we should still allow each PerformanceEntry the ability to have functions unique to its needs, if needed. We had discussed at that time whether or not we should keep the getMeasures/getMarks functions and had decided to keep them. The arguments made then, http://lists.w3.org/Archives/Public/public-web-perf/2011Jun/0077.html, still hold true now.

In particular, some developers may only be interested in measuring their custom scenarios that they've instrumented via marks and measures and not all other PerformanceEntries.  Uploading just the measure times may be in the few bytes range vs. uploading a full list of Navigation Timing, Resource Timing, and User Timing in their full, verbose JSON object format. Even if using getEntriesByType("mark"), a developer may truly only be interested in the mark/measure data and not the additional data like startTime and entryName.  The getMarks() interface also "groups" same-named marks into a single entry, with a name:[timestamp array] association, whereas getEntriesByType would return a new object for every mark timestamp.

As Pan mentioned, getMarks and getMeasures return marks and measures according to the order of when they were added, whereas getEntriesByType and getEntriesByName return entries sorted according to chronological order defined by startTime. I believe there is value in both looking at the entire timeline in the correct timeline order and looking at just the marks/measures in the order you added them.

I think we should keep them.

Thanks,
Jatinder

From: Deng, Pan [mailto:pan.deng@intel.com]
Sent: Monday, July 09, 2012 10:14 PM
To: James Simonsen; public-web-perf
Subject: RE: [User Timing] Integration with Performance Timeline

I agree that return PerformanceEntryList via PerformanceTimeline is clearer than object/Array, even if there are two entries with the same "type" and "name".

However, about replacing getMarks() and getMeasures(), my concern is, when script user use getMeasures(specificMeasureName), they may want entries "in the order with respect to they call measure()", Eg:
performance.mark('mark1');   //assume HR timestamp 1.0 attached
performance.mark('mark2'); // assume HR timestamp 2.0 attached
performance.mark('mark3'); // assume HR timestamp 3.0 attached

performance.measure('measureA', 'mark2', 'mark3');     // measure duration 1.0
performance.measure('measureA', 'mark1', 'mark3'); // measure duration 2.0

performance.getMeasures('measureA'); // script user may want [1.0, 2.0] in the order they call measure;

while when they use getEntriesByName(), they will get entries "in chronological order with respect to startTime", eg:
performance.getEntriesByName('measureA', 'measure'); // entrylist contains [{'measureA', 2.0...}, {'measureA', 1.0, ...}] will be returned.

I think it will be better if handle semantic differentiation.

Pan




From: simonjam@google.com<mailto:simonjam@google.com> [mailto:simonjam@google.com]<mailto:[mailto:simonjam@google.com]> On Behalf Of James Simonsen
Sent: Tuesday, July 10, 2012 5:01 AM
To: public-web-perf
Subject: [User Timing] Integration with Performance Timeline

Hi web-perf fans,

I was inspired to review the User Timing patch after seeing patches posted for it to WebKit. It looks like there's one thing we could clean up now that we have the Performance Timeline spec.

getMeasures() and getMarks() should be replaced by getEntriesByType() and getEntriesByName(). The whole point is to have a single interface instead of each timing spec adding its own accessors.

I realize part of this was to get the clever behavior of returning a PerformanceEntry instead of an array if there's only one, but I think that feature will end up confusing users (how are they supposed to code for it?). Plus I doubt it's compliant with WebIDL.

James