Re: Alternate User Timing API

Rajiv, thanks for the feedback! I agree that the current API is a bit

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 <> 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:; }
> ....
>   var secondObj = { mark:; }
> ...
>   console.log(`Time passed: ${firstObj.mark - secondObj.mark}`);
> That is, if you just want something representing "the now point in time",
> 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
- 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.


Received on Thursday, 26 November 2015 06:03:31 UTC