Performance marker linking proposal

[Eli Perelman]

Hello,

With the User Timing API [1], it will be possible for sites and applications to create arbitrary markers in JavaScript to denote important moments in its lifecycle.

```js

// Example: Dialer app denoting the call log is ready

performance.mark('callLogReady');

```

These markers are accessible using `performance.getEntriesByType('mark')`, and each entry contains an object with metadata associated with the timing of the marker.

This API has not yet been implemented in Gecko [2], but is currently live in Chrome and IE. In order to make this API more useful for performance testing, I would like to propose an API available to the System app for creating linked performance markers.

As an example, I'll take the common application launch scenario. While using the homescreen and the user taps an icon to launch an app, ideally it would create a marker to denote the moment of user intent. Then in the System app, another marker would be created to denote the moment of the instantiation of the app window. Finally, the application itself would create markers implying its own loading progress. The System app should have a mechanism for tying all these markers together so we can report a timeline of the entire interaction.

There are many more scenarios for linking markers than this, but I hope this conveys the idea. For even more value in performance testing though, I also believe that the System app should receive events when markers are created. This will enable us to use the proposed API at the correct moment to fetch the linked marker data with relevant metadata to know for which context it was generated against.

Using these two mechanisms together would greatly improve the efficiency and expand the functionality for Gaia to do performance testing and would pave the way for more insightful developer tooling. I welcome any comments and suggestions to get the ball rolling on this idea.

[1] http://www.w3.org/TR/user-timing/

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=782751

Thanks,

Eli Perelman

Software Engineer, Firefox OS

[Ting-Yu Chou]

Eli,

I really like User Timing API, it indeed helps for things like bug 1063708 and
bug 1074783.

But I am not sure I understand your idea correctly. As a user, when I add
markers, I usally expect them to be shown on a single timeline, so what will
linked markers help? I mean, for the use case you mentioned, what's the value
linked markers offer more than unlinkd markers?

Or will there be multiple timelines?

Thanks,
Ting

> _______________________________________________
> dev-b2g mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-b2g
>

[pro...@mozilla.com]

We are doing exactly that but with a different API in the timeline.

The Console API comes with 2 methods:
- console.time(aStr);
- console.timeEnd(aStr);

It looks like this in Firefox' timeline:
http://i.imgur.com/EqHTQde.png
http://i.imgur.com/TUSdORn.png

Bug 1050502 (about to land) will add a marker in the timeline when timeEnd is called.

[Eli Perelman]

Hey Paul,

I think that visualization lines up with what will happen with performance.measure(), showing durations instead of markers (which use for performance.mark()). The difficult situation is aggregating markers and durations across processes and having them represented as if they occurred within a single page. Not to mention these APIs can also be used to aggregate performance data which we do analysis in using external tools like Datazilla. I think those are the main differences between the APIs, and why we need another mechanism for linking between processes.

My instinct tells me that upon creating a performance.mark/measure, we should be able to store some additional metadata with the instance that contains the URL of the page/app generating the indicator. We can then use this in the System app/parent process to aggregate all markers of a certain origin to build out a timeline, etc. Just throwing ideas out there, as I have no idea how we would actually annotate a marker without changing the spec.

Thanks,

Eli Perelman

Software Engineer, Firefox OS

[Eli Perelman]

The idea, at least for the devtools visualization, would be for markers and measurements that occur in different processes to be displayed on the existing timeline. For example, if I create a marker in the System app that is linked to an action that occured in the Contacts app, that marker should be displayed in the Contacts timeline. Likewise if I create a linked measurement in verticalhome and System that is contextually bound to another app, it should display as a duration in that app's timeline.

For performance testing, it's pretty much the same concept, but we need the data to be compatible between processes. If an app creates a timestamp using performance.now(), and the System does the same, there isn't currently a mechanism that we can use to compare the deltas between the two timestamps. Having a way to link markers will let us compare high-resolution timestamps across processes.

Does that makes sense?

Thanks,

Eli Perelman

Software Engineer, Firefox OS

> Thanks,
>
> Eli Perelman
> Software Engineer, Firefox OS
>

[Paul Rouget]

Eli Perelman wrote:
> The idea, at least for the devtools visualization, would be for markers and
> measurements that occur in different processes to be displayed on the
> existing timeline. For example, if I create a marker in the System app that
> is linked to an action that occured in the Contacts app, that marker should
> be displayed in the Contacts timeline. Likewise if I create a linked
> measurement in verticalhome and System that is contextually bound to
> another app, it should display as a duration in that app's timeline.
>
> For performance testing, it's pretty much the same concept, but we need the
> data to be compatible between processes. If an app creates a timestamp
> using performance.now(), and the System does the same, there isn't
> currently a mechanism that we can use to compare the deltas between the two
> timestamps. Having a way to link markers will let us compare
> high-resolution timestamps across processes.
>
> Does that makes sense?

Right. The devtools can only show data coming from one process, and there's
no plan to aggregate data from different app/process.

So the aggregation needs to be done at the platform level or at the app level.
Whatever API and mechanism you choose, if you want the markers to show-up in
the devtools, the only thing you need is to call:

If it has a duration:

docShell->AddProfileTimelineMarker("aMarkerID", TRACING_INTERVAL_START);
docShell->AddProfileTimelineMarker("aMarkerID", TRACING_INTERVAL_END);

Or if it's one-time event:

docShell->AddProfileTimelineMarker("aMarkerID", TRACING_EVENT);

docShell being the top level docshell of the app.

-- Paul

[Thinker K.F. Li]

We encounter a similar issue for tasktracer.
One kind of use cases is to mark the time of an event.
It does not intent to measure the length of a duration.
For now, tasktracer hooks on console.log() to pick up messages with a
predefined prefix string. I am not sure if it deserves a new API.

--
Sinker
--
天教懶漫帶疏狂