Resolve pc.now to native function

[kungfooman]

I was doing some benchmarking and even now appeared, so I tried to optimize it somewhat:

I made this little benchmark:

console.clear();
const n = 1_000_000;
function runDateNow() {
  for (var i=0; i<n; i++) {
    Date.now();
  }
}
const dateNow = Date.now;
function runDateBound() {
  for (var i=0; i<n; i++) {
    dateNow();
  }
}
function pcNow() {
  return window.performance.now();
}
function runNow() {
  for (var i=0; i<n; i++) {
    pcNow();
  }
}
const pcNowBound = performance.now.bind(performance);
function runNowBound() {
  for (var i=0; i<n; i++) {
    pcNowBound();
  }
}
tests = [
  runDateNow,
  runNow,
  runNowBound,
];
results = [];
function testAll() {
  for (const test of tests) {
    const start = performance.now();
    test();
    const end = performance.now();
    results.push([test.name, Math.round(end - start)]);
    console.clear();
    results.sort((a, b) => {
      const ret = a[0].localeCompare(b[0]);
      if (ret === 0) {
        return b[1] - a[1];
      }
      return ret;
    });
    console.table(results);
  }
}
testAll();
testAll();
testAll();
testAll();
testAll();
testAll();

(can be pasted in F12/devtools for quick testing)

Results (number is milliseconds, smaller = faster):

TLDR: less code + faster, because its not going through the extra function callback anymore:

Previously:

I confirm I have read the contributing guidelines and signed the Contributor License Agreement.

[LeXXik]

I think performance.now() has a higher precision and is a better fit for measuring time between stamps, than Date.now(). Perhaps there could be 2 versions, one with Date.now() and used in, say, UI buttons, where high precision is not needed. The other would then be used in debug builds for measuring performance times.

[mvaligursky]

This looks fine to me .. tiny improvement per call, but why not. Functionality is the same, it just avoids the look up from the window.

The reason this shows on the profiler is not that the function is slow .. it takes around 0.001ms per call based on your numbers. But browser runs sampling profiler at low frequency to avoid impact of the profiler, and the sample hit the function directly. Next sample was 0.11ms later and hit different function. It does not mean the now took 0.11ms there.

[kungfooman]

I think performance.now() has a higher precision and is a better fit for measuring time between stamps, than Date.now(). Perhaps there could be 2 versions, one with Date.now() and used in, say, UI buttons, where high precision is not needed. The other would then be used in debug builds for measuring performance times.

For my sake both timing functions are fast enough, what I want to focus on is the difference between two kinds of calls:

Current now implementation, going through an extra function and window lookup:

function pcNow() {
  return window.performance.now();
}

And as bound function which is called as native bound function without wrapper function nor window lookup:

const pcNowBound = performance.now.bind(performance);

Functionality is the same, it just avoids the look up from the window.

Yep, in my projects I apply many getters/setters to window and then the window lookup can make more impact than usual:

(its relatively 6x faster, but not much overall as you say)

[mvaligursky]

looks good to me, I don't see any problems with this.