ChromeUtils.addProfilerMarker - new API to add profiler markers from JS code

Florian Quèze florian at queze.net
Tue Apr 7 13:22:32 UTC 2020


I recently landed a new scriptable API
<https://bugzilla.mozilla.org/show_bug.cgi?id=1608556> to add profiler
markers: ChromeUtils.addProfilerMarker.
This makes it possible for chrome privileged JS code to insert profiler
markers that (optionally) have a duration and an associated text.

Examples:

   - Adding a marker without duration:
   ChromeUtils.addProfilerMarker("markerName");
   - Adding a marker showing the time it took to do something:
   let startTime = performance.now();
   /* do stuff */
   ChromeUtils.addProfilerMarker("markerName", startTime);
   The performance object is available in windows and workers. In JS
   modules, use Cu.now() instead of performance.now().
   - Adding a marker with a duration and an associated extra string:
   ChromeUtils.addProfilerMarker("markerName", startTime, "marker text");


Hopefully, this should make it easier to show clearly in the profiler what
our JS code is doing. The first use I made of this was to show the OS.File
operations that are done asynchronously (example profile:
https://perfht.ml/2RhAKXF).

Scriptable marker APIs that already existed:

   - Adding a marker from XPCOM-enabled contexts:
   if (Services.profiler) {
     Services.profiler.addMarker("markerName");
   }
   The null check was required to avoid exceptions on tier3 platforms that
   don't implement the profiler service.
   We will probably want to deprecate this API and migrate all existing
   callers.
   - Adding a 'UserTiming' marker with a duration in a window or worker:
   performance.mark("markName");
   /* do stuff */
   performance.measure("marker text", "markName");
   This will add a marker named UserTiming with the "marker text"
   associated text, and the duration between the performance.mark and the
   performance.measure calls. However, the performance.measure
   implementation is slow
   <https://bugzilla.mozilla.org/show_bug.cgi?id=1373086> enough that it
   adds significant overhead if called frequently.
   This API will remain available, but should be avoided for chrome
   privileged code.


-- 
Florian Quèze
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20200407/b40b4bf5/attachment.html>


More information about the firefox-dev mailing list