If we're concerned about performance, new Date(now) is still being evaluated here every time, no matter whether debug() is a no-op or not.

I've timed benchmark/settimeout.js with and without that debug statement and I couldn't find a measurable difference.

@mscdex You are right that the arguments of debug() are immediately evaluated in regardless of NODE_DEBUG and it seems to affect the performance. But it is called only once in benchmark/settimeout.js because all timeout callbacks are stored in the same timer array as 1000.
If the delay timers of setTimeout()'s are all different in a benchmark, the debug()s are called at every ontimeout callbacks, however, their overheads are not accumulated as long as they are finished within 1msec so that we need not worry about it.

Guys, take a look at the https://github.com/AlexeyKupershtokh/node-perf-time project.
I understand that caching time is usually a bad idea, but probably it's the place it worth using it. It has some drawbacks though, so if you are interested, please check the module's principles.

I've modified your lib/timers.js & benchmarks/settimeout.js sources, you can find them at https://github.com/AlexeyKupershtokh/node-perf-time/tree/master/bench/settimeout
The results are:

wicked@wicked-desktop:~/node-perf-time/bench$ node settimeout.js
wait...
smaller is better
startup: 12263
done: 1299

wicked@wicked-desktop:~/node-perf-time/bench$ node settimeout2.js
wait...
smaller is better
startup: 4752
done: 1001

Practically the mail project's weaknesses are garbage collection and cycles like this:

for (i = 0; i < 1000; i++) {
  var now = t.get();
  long_sync_stuff_that_does_not_get_time(now); // there is no t.get() inside
}

In this case time cache can stale for milliseconds or even seconds because neither rate-flush nor settimeout-flush would work.