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] 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

Received on Tuesday, 10 July 2012 05:14:27 UTC