Measuring JavaScript execution time Topic is solved

[UCyborg]

Is there a way to get more precision out of performance.now() on UXP? Because it seems to be returning plain integer, for one thing I'm measuring, either 0 or 16 (ms), nothing in between. I'm looking for something like WIN32's QueryPerformanceCounter() or at least timeGetTime(), for JavaScript, but all I'm getting on UXP is more like GetTickCount().

[Moonchild]

The limited precision in JavaScript is entirely on purpose for security reasons. Multiple side-channel attacks exist that could use high-accuracy timers.
Currently, we clamp performance timers to a granularity of 2 ms. See https://xref.palemoon.org/goanna-centra ... amping.cpp
Depending on what you're trying to measure, you might also be limited to the refresh driver ticking over which would explain the 16 ms (which is ~60 Hz)

[UCyborg]

So I heard, just wondered if there's an override in about:config.

Which leads to the next question, how do you figure if certain code snippet goes through faster than another? Other than by measuring on another browser engine and hoping it's faster here too. Well, parts that may be super slow already are straightforward if the faster version is significant enough to be picked up by less precise timing.

[Moonchild]

The common way to more accurately benchmark is to measure runs/s, not raw timing.
i.e. measure a start time, then run your test in a loop incrementing a counter to keep track of the number of loops performed, until at least end time - start time > 1s (or multiple for accuracy), then just divide the loops run through (counter) by the actual time taken (end - start, adjusted to seconds) to get the benchmark score.

As for a preference, no, we currently don't have a preference for this. Although we may want to revisit this to make it a bit more fine-grained again as spectre and meltdown have been mitigated and/or are no longer as much of a concern on current hardware.

[UCyborg]

Of course, how could I forget? I should go to sleep earlier.