Skip to content
This repository has been archived by the owner. It is now read-only.
Permalink
Browse files

timer: change new Date to Date.now for performance

Speeds up benchmark/settimeout.js by about 30%.
  • Loading branch information...
Shigeki Ohtsu authored and bnoordhuis committed Jul 10, 2012
1 parent f210530 commit 76104f3414f10bd5df1aa8cdc69cff9f73e64b9d
Showing with 4 additions and 4 deletions.
  1. +4 −4 lib/timers.js
@@ -51,7 +51,7 @@ var lists = {};
// the main function - creates lists on demand and the watchers associated
// with them.
function insert(item, msecs) {
item._idleStart = new Date();
item._idleStart = Date.now();
item._idleTimeout = msecs;

if (msecs < 0) return;
@@ -71,8 +71,8 @@ function insert(item, msecs) {
list.ontimeout = function() {
debug('timeout callback ' + msecs);

var now = new Date();
debug('now: ' + now);
var now = Date.now();
debug('now: ' + (new Date(now)));

This comment has been minimized.

Copy link
@mscdex

mscdex Jul 10, 2012

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.

This comment has been minimized.

Copy link
@bnoordhuis

bnoordhuis Jul 10, 2012

Member

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

This comment has been minimized.

Copy link
@shigeki

shigeki Jul 11, 2012

@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.

This comment has been minimized.

Copy link
@AlexeyKupershtokh

AlexeyKupershtokh Oct 22, 2012

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

This comment has been minimized.

Copy link
@AlexeyKupershtokh

AlexeyKupershtokh Oct 22, 2012

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.


var first;
while (first = L.peek(list)) {
@@ -155,7 +155,7 @@ exports.active = function(item) {
if (!list || L.isEmpty(list)) {
insert(item, msecs);
} else {
item._idleStart = new Date();
item._idleStart = Date.now();
L.append(list, item);
}
}

0 comments on commit 76104f3

Please sign in to comment.
You can’t perform that action at this time.