Low impact date/time getters.
Switch branches/tags
Nothing to show
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.


‼️ Warning: Usually Date.now() works quite fast (> 10,000,000 ops/sec) and you don't need this module. But in some systems like in my case (Ubuntu 12.04 32 bit + pae) it works 15-20 times slower than it should. I recommend upgrading your system but if you can't than this module can be useful for you. This is a system-wide problem so you can check your Date.now() performanice in a browser (FF or Chrome) and the node's Date.now() will likely show the same results. ‼️


Low impact date/time getters.

+new Date               x  1,106,626 ops/sec ±0.80% (99 runs sampled)
Date.now()              x  1,418,551 ops/sec ±0.16% (101 runs sampled)
process.hrtime()        x    833,820 ops/sec ±0.16% (101 runs sampled)
process.uptime()        x  1,244,217 ops/sec ±0.24% (100 runs sampled)
microtime.now()         x  1,247,487 ops/sec ±1.03% (100 runs sampled)
perfTime(1000000).get() x 24,040,578 ops/sec ±1.85% (85 runs sampled)
perfTime(100000).get()  x 18,311,654 ops/sec ±0.51% (93 runs sampled)
perfTime(10000).get()   x  8,393,439 ops/sec ±0.37% (97 runs sampled)
perfTime(2000).get()    x  3,362,967 ops/sec ±0.30% (100 runs sampled)
perfTime(900).get()     x  1,375,311 ops/sec ±0.17% (101 runs sampled)


npm install perf-time


var perfTime = require('perf-time');

var t = new perfTime();
console.log(t.get()); // outputs: 1350895024399

// set custom rate
var t = new perfTime(10000);
console.log(t.get()); // outputs: 1350895024403

// set custom provider instead of default Date.now()
var provider = function() { return (new Date).getMilliseconds(); };
var t = new perfTime(provider);
console.log(t.get()); // outputs 403


This class caches calls to time getters. This cache is flushed in two ways:

  • Every 100th iteration (by default) during blocking code.
  • Every millisecond using setTimeout(..., 1).

Pros and cons

  • 😄 Works accurate enough when you don't have long blocking code.
  • 😄 Works accurate enough when you have long blocking code but calculate time often enough (at 100K/sec rate).
  • 😓 Can work inaccurate when you have long blocking code with time calculations at lower rates. Just pass the required rate for this case for improving accuracy.
  • 😄 You can use higher rates to trade accuracy for performance.
  • 😰 Garbage collection in node.js can take hundreds of milliseconds and is executed synchronously. Therefore it will make perf-time usually stale after gc till next cache flushing.