969490 - Implement Components.utils.now() to match Performance.now() for non-window chrome code

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[:Irving Reid (No longer working on Firefox)]

+++ This bug was initially created as a clone of Bug #908390 +++

Telemetry, and probably other clients, need better timing that we get from Date.now(). Telemetry probes don't always run in a window context, so we would like an equivalent to window.performance.now() that works for non-window chrome.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Do you care what the timebase is?  In particular, do you want a shared timebase across all chrome, or is a pretty much random timebase per-global (e.g. stored in the per-global performance object itself) sufficient?

Comment 2

[:Irving Reid (No longer working on Firefox)]

Most of the current timestamp collection in Telemetry assumes a shared timebase (interval since application launch). Switching those uses to a per-global time base would cause quite a few headaches.

There are some uses where we're explicitly collecting time intervals; those would be fine with per-global (or even per-interval-collector) bases.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Alright.

Note that window.performance.now() has a per-window timebase.  Is that going to be a problem, given the "don't always" (as opposed to "don't") in comment 0?

Comment 4

[:Irving Reid (No longer working on Firefox)]

Hmm. Thinking about that more, the best approach may be to expose StartupTimeline (probably with a few tweaks) to JS for recording events relative to application startup with a consistent time base, and use performance.now() (or perhaps a less error-prone "timer = performance.startTimer(); ... timer.now()") for recording intervals.

The main problem *I'm* trying to fix is that we see enough negative time intervals in our current telemetry data that it's sometimes obscuring the signal. Higher precision would be nice, but my first goal is to avoid having our data messed up by bogus time comparisons, whether from system clock skew or inconsistent time bases.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Ah, nice.

We can certainly add a chrome-only (e.g. Components.now() or Components.performance.now()) API that returns the number of milleseconds from StartupTimeline::Get(PROCESS_CREATION), say.  Bobby, any better places to hang this off of?

How fast do you want the timer calls to be?  Components.now() would probably take about 1us per call.  We could make performance.now() about 50ns per call if you already have the "performance" object and aren't actually getting it off anywhere as part of the call.  Otherwise you're probably back to 1us.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Bobby, how do you feel about Components.now()?

Comment 7

[:Irving Reid (No longer working on Firefox)]

Telemetry use cases don't need to be super fast; we're mostly interested in milliseconds. 1μs would be fine, though if it's not much work, less overhead is always nice.

Comment 8

[Bobby Holley (:bholley)]

(In reply to Boris Zbarsky [:bz] from comment #6)
> Bobby, how do you feel about Components.now()?

Directly on Components is a no-go, but Components.utils.now would be fine as long as nobody minds the XPConnect call overhead.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Attachment: Add a Components.utils.now() that provides access in system JS to a monotonic timer, returning a fractional number milliseconds since process creation

Comment 10

[Bobby Holley (:bholley)]

Comment on attachment 8483863 [details] [diff] [review]
Add a Components.utils.now() that provides access in system JS to a monotonic timer, returning a fractional number milliseconds since process creation

Review of attachment 8483863 [details] [diff] [review]:
-----------------------------------------------------------------

::: js/xpconnect/src/XPCComponents.cpp
@@ +3553,5 @@
>      return NS_OK;
>  }
>  
> +NS_IMETHODIMP
> +nsXPCComponents_Utils::Now(double* aRetval)

* goes on the right.

Comment 11

[Boris Zbarsky [:bzbarsky]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/4934b1907579

Comment 12

[Boris Zbarsky [:bzbarsky]]

Er, I meant https://hg.mozilla.org/integration/mozilla-inbound/rev/6ed2082c2e48

Comment 13

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/6ed2082c2e48

Comment 14

[Gabriele Svelto [:gsvelto]]

I hadn't noticed this before so I'll just leave a comment FYI. When I addressed bug 793735 I modified the getStartupInfo() call to return an adjusted value of the Date that would be relative to Date.now(). That was made to prevent cases where Date.now() would appear before the data gathered via getStartupInfo(). This also means that doing something like this in chrome code:

function uptime() {
  return Date.now() - Services.startup.getStartupInfo().process;
}

will yield a monotonic timer that always returns the number of ms elapsed since startup. The change here provides equivalent functionality in a cleaner way than what I did there:

http://hg.mozilla.org/mozilla-central/file/db7212847c14/toolkit/components/startup/nsAppStartup.cpp#l124
http://hg.mozilla.org/mozilla-central/file/db7212847c14/toolkit/components/startup/nsAppStartup.cpp#l778