I'm pretty sure that if you're not in the System Principal; your
timestamps from the performance object are going to be clamped to 1ms
resolution (and potentially jittered forward....)
I'm not sure in what context this will be used; or if there's
something that would prevent this timing behavior from taking effect;
but it would be worth confirming and documenting I think.
-tom
On Tue, Apr 7, 2020 at 8:22 AM Florian Quèze <flor...@queze.net> wrote:
>
> I recently landed a new scriptable API 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 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
> _______________________________________________
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
