Re: Alternate User Timing API

Opened a GH issue, so we don't lose this:
https://github.com/w3c/user-timing/issues/14

On Wed, Nov 25, 2015 at 10:02 PM, Ilya Grigorik <igrigorik@google.com>
wrote:

> Rajiv, thanks for the feedback! I agree that the current API is a bit
> limiting..
>
> Another example that came up recently in my own work: I wanted to emit a
> measure that captured [event.startTime -> end of my handler function], but
> today that is not possible because event.startTime != when my handler
> receives the event, and performance.measure does not accept timestamps as
> start/end parameters. A simple solution here would be to accept
> DOMHighResTimestamps as start and end parameters..
>
> That said, before we jump to solutions, I'm curious if anyone else on this
> list has other examples or scenarios that are not possible, or tricky to
> implement with existing User Timing API?
>
> On Wed, Nov 25, 2015 at 2:08 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>
>> On 11/23/15 4:28 PM, Rajiv Tirumalareddy wrote:
>>
>>> I want to propose an API where a call to `performance.mark()` returns a
>>> unique javascript object, lets call it a marker. And when I call
>>> `performance.measure()` I should be able to pass to it two markers and
>>> have it record the time between the markers.
>>>
>>
>> How is this different from:
>>
>>   var firstObj = { mark: performance.now(); }
>> ....
>>   var secondObj = { mark: performance.now(); }
>> ...
>>   console.log(`Time passed: ${firstObj.mark - secondObj.mark}`);
>>
>> That is, if you just want something representing "the now point in time",
>> performance.now() is it.  The idea with mark() and measure() is so you
>> don't have to cart around the time at which mark() was called to figure out
>> how much time has passed when measure() is called.
>
>
> Yes, but our current definition also has a number of limitations:
> - doesn't work when you receive a timestamp from elsewhere (e.g.
> dispatched events)
> - marks require unique names, which quickly breaks down when working with
> repeating events
> - while it's easy enough to compute duration between any two timestamps
> (as your example illustrates), you can't emit a PerformanceMeasure into the
> timeline unless you have unique mark names.. which means tooling+analytics
> can't see or log such events.
>
> ig
>