[nodejs] An idea how to probably improve Date.now() (new Date, etc.) speed.

I don't really care about speeding up Date.now() because it's already
near optimal from a performance perspective. On Linux systems, it
doesn't even require a system call, it simply reads the timestamp from
the VDSO.

Weeding out new Date() call sites is generally a good thing: the Date
constructor is about 3x as slow as Date.now() and uses more memory to
boot. I don't expect to see user-visible improvements outside of
micro-benchmarks, though.

Re: --prof, I don't quite see how it's connected to all this but yes,
the profiler runs once every millisecond. It's a separate thread that
wakes up at fixed intervals and records the main thread's instruction
pointer (and some other bits).

Actually, the profiler always runs, regardless of whether or not you
specified --prof. It's what V8 uses to find out what code is hot.

Currently after removing one excessive call to Date.now makes the other
Date.now call require as much time as all the other logic in setTimeout() +
active() + all the _linklist stuff (L.isempty, L.remove, L.append, etc.). I
think it can be better.

Looking from another side, Date.now() can be calculated about 1.4M ops/sec
rate on my pc. But EventEmitter can perform at 5-20M ops/sec in simple emit
scenarios.

Ok, let's take into account an http benchmark, you were referring
https://github.com/joyent/node/issues/4191 . How many Date.now() are
performed for each request? Let's say this number is 1. Let's calculate
Date.now cpu usage: 21K/1.4M is 1.5% spent only on time calculation. Is it
that much to optimize? I don't actually know.

So I would say, that Date.now() is fast enough but not optimal.

Regarding the --perf, let me show the concept:
var ts = null;
Date.now = function() {
if (!ts) return ts = gettimeofday(2);
return ts;
};
Thread that ticks every millisecond, similar to profiler's thread, just
flushes the cache:
{
ts = null;
}

This way Date.now is cached ad most for 1ms and during this 1ms is always
returned from the variable.
new Date() could be then behave like new Date(ts);

That's it.

пятница, 26 октября 2012 г., 8:05:15 UTC+7 пользователь Ben Noordhuis
написал:

When it comes to performance, don't guess or assume - benchmark it.
Clone the repo, try out your changes and see what difference it makes
on benchmark/http_simple or benchmark/http_simple_auto.

Ok then.

cp benchmark/http_simple_auto.js benchmark/http_simple_auto2.js
edit benchmark/http_simple_auto2.js and add this code at the start:
var n = 1000;
var now = Date.now();
Date.now = function() {
if (n-- == 0) {
n = 1000;
now = Date.now();
}
return now;
}

Make sure you have a version that already uses Date.now() in timers.js
instead of new Date();

RPS for the benchmarks in a few runs in turn, sorted by asc:
benchmark/http_simple_auto.js: 15635, 15739, 16025, 16076, 16091; avg
= 15913
benchmark/http_simple_auto2.js: 16402, 16735, 16783, 16815, 16881; avg
= 16723
16723 / 15913 = 1.051
So the http_simple_auto2.js is overall 5% faster just because of speeding
up Date.now().

пятница, 26 октября 2012 г., 10:51:15 UTC+7 пользователь Ben Noordhuis
написал:

I disagree to re-implement Date.now() within Node because it is defined
in ES5 and V8 should take care of its performance.

In timer case, there is an alternative to use process.hrtime() instead
of Date.now(). I've just made a quick hack to use it in

https://github.com/shigeki/node/compare/test_hrtime

for benchmark.

I tested http_simple_bench.sh but there seems no significant difference
as below.

./benchmark/http_simple_bench.sh with Date.now() in timer
ab-hello-world-buffer-102400 Requests per second: 1548.97 [#/sec]
ab-hello-world-buffer-1024 Requests per second: 1755.29 [#/sec]
ab-hello-world-string-102400 Requests per second: 459.39 [#/sec]
ab-hello-world-string-1024 Requests per second: 1919.99 [#/sec]


./benchmark/http_simple_bench.sh with process.hrtime() in timer
ab-hello-world-buffer-102400 Requests per second: 1491.16 [#/sec]
ab-hello-world-buffer-1024 Requests per second: 1748.89 [#/sec]
ab-hello-world-string-102400 Requests per second: 612.75 [#/sec]
ab-hello-world-string-1024 Requests per second: 1953.58 [#/sec]

(2012/10/26 16:38), Alexey Kupershtokh wrote:

Ok, if re-implementing is not an option, then we could just add optimized
version with different name. Or even write an external module. It doesn't
matter.

And process.hrtime() is even slower than Date.now();

+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)
microtime.now() x 1,247,487 ops/sec ±1.03% (100 runs sampled)


пятница, 26 октября 2012 г., 16:39:14 UTC+7 пользователь shigeki написал:

For .hrtime(), are you considering the fact that it's returning an Array,
while Date.now() is returning an integer? v8 has some crazy optimizations
for the later case. Also, are you considering how much time your actual
loop costs or how many runs of Date.now() before incurring 10ms of
performance hit?

While there might be a better way, it's so fast already that there are much
more important things on the map. Like TLS performance.

Now, I'm not saying it's as fast as it could be. Take the following three
cases:

var len = 1e8,
i = 0;
while (++i <= len) { }

output:

real 0m0.287s
user 0m0.280s
sys 0m0.004s

So I'm doing around 348,432,055/sec. Now the following:

var len = 1e8,
i = 0;
while (++i <= len) {
Math.random();
}

output:

real 0m0.881s
user 0m0.872s
sys 0m0.012s

So I'm doing around 125,000,000/sec. Now the final:

var len = 1e8,
i = 0;

while (++i <= len) {
Date.now();
}

output:

real 0m4.183s
user 0m4.176s
sys 0m0.016s

Which is around 23,906,287/sec.

So yeah, there might be some performance improvements. But not enough to
warrant a re-write of the method.

trev

Trev, Looking at your numbers I totally agree with you.
But I can't repeat these numbers and have the following9\:

wicked@wnote:$ time node 1.js

real 0m0.273s
user 0m0.260s
sys 0m0.016s
wicked@wnote:~$ time node 2.js

real 0m0.874s
user 0m0.864s
sys 0m0.012s
wicked@wnote:~$ time node 3.js

real 2m28.589s
user 0m27.638s
sys 2m2.340s

It's 673,400/sec. Which is around 23,906,287/sec which is 35 times slower
than your case :(

In both node 0.8.14 taken from Chris Lee's debs and 0.9.2 compiled on my
laptop.
So the question transforms into "why is date.now so damn slow for me"

суббота, 27 октября 2012 г., 7:10:51 UTC+7 пользователь Trevor Norris
написал:

It's pretty quick for me. I noticed that your timing is 27secs for user,
and 2 minutes for system. When you run it, is there any CPU usage?

Try this on google chrome & some other browser to see if it's a node, v8 or
computer related problem...

http://jsperf.com/new-date-value/9

Cpu usage of other proceses is about 3-5%. When node 3.js was running top
showed:

Cpu(s): 13.8%us, 41.6%sy, 0.0%ni, 43.6%id, 1.0%wa, 0.0%hi, 0.0%si,
0.0%st

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND


12672 wicked 20 0 35192 9104 4204 R 101 0.1 0:42.00 node


17368 wicked 20 0 275m 86m 23m S 2 1.4 5:09.69 chrome
...

You can find the "Chrome 23.0.1271 (1)" on
http://jsperf.com/new-date-value/9 which is much slower than others.
Date.now() is 583,442 only. Very interesting results.
So I must conclude it's not only node-related but the overall v8's Date.now
is affected.

wicked@wnote:~$ cat /etc/issue
Ubuntu 12.04.1 LTS \n \l

wicked@wnote:~$ uname -a
Linux wnote 3.2.0-33-generic-pae #52-Ubuntu SMP Thu Oct 18 16:39:21 UTC
2012 i686 i686 i386 GNU/Linux



воскресенье, 28 октября 2012 г., 0:26:10 UTC+7 пользователь niknah написал:

Testing in Firefox 16.0 on Ubuntu
Date.now() is 713,232 /s
Seems it's even system-wide. How to fix this?

PS: My CPU is Intel® Core™ 2 Duo P7350(2GHz, 1 066MHz, 3Mb).

воскресенье, 28 октября 2012 г., 1:30:35 UTC+7 пользователь Alexey
Kupershtokh написал:

Do I understand correctly that this code is responsible for Date.now() ?
https://github.com/joyent/node/blob/v0.9.2/deps/v8/src/date.js#L312
https://github.com/joyent/node/blob/v0.9.2/deps/v8/src/runtime.cc#L9239

https://github.com/joyent/node/blob/v0.9.2/deps/v8/src/platform-nullos.cc#L108
https://github.com/joyent/node/blob/v0.9.2/deps/v8/src/platform-posix.cc#L170
https://github.com/joyent/node/blob/v0.9.2/deps/v8/src/platform-win32.cc#L586

воскресенье, 28 октября 2012 г., 1:36:45 UTC+7 пользователь Alexey
Kupershtokh написал:

Testing in Chrome 22.0.1229.94 on Windows Vista:

Using .valueOf() | new Date().valueOf(); | 3,041,709±0.52% | 57% slower
Using .getTime() | new Date().getTime(); | 3,123,610±0.40% | 55% slower
Using +new Date() | +new Date(); |1,945,890±5.94% | 74% slower
Using +new Date | +new Date; |2,050,588±3.42% | 72% slower
Date.now() | Date.now(); | 7,010,134±0.51% | fastest
Date.now() | dereferenceddatenow(); | 6,995,289±0.81% | fastest

Node.js 0.8.14 installed from official msi:
D:\work\node>node 1.js
Finished in 205 ms, 487,804,878 ops/sec

D:\work\node>node 2.js
Finished in 899 ms, 111,234,705 ops/sec

D:\work\node>node 3.js
Finished in 14412 ms, 6,938,662 ops/sec

It's 10 times faster than in ubuntu.
I have 2 very different:
1) laptop with ubuntu 12.04 x86 with PAE & windows vista
1) PC with ubuntu 11.04 x86 with PAE
(PAE is https://help.ubuntu.com/community/EnablingPAE )

So there's a problem with Date.now() in node, chrome and firefox in both
ubuntus.

воскресенье, 28 октября 2012 г., 2:44:05 UTC+7 пользователь Alexey
Kupershtokh написал:

I've found an extreme solution:

I upgraded ubuntu from
Ubuntu 12.04.1 LTS \n \l;
Linux wnote 3.2.0-33-generic-pae #52-Ubuntu SMP Thu Oct 18 16:39:21 UTC
2012 i686 i686 i386 GNU/Linux
to
Ubuntu 12.10 \n \l;
Linux wnote 3.5.0-17-generic #28-Ubuntu SMP Tue Oct 9 19:31:23 UTC 2012
x86_64 x86_64 x86_64 GNU/Linux

And performance increased 15-20 times to these numbers:


1. Chrome 22: 10,946,261
2. FF 16: 15,301,293
3. Node 0.8.14: 11,671,335


Differences are:
ubuntu: 12.04 -> 12.10
kernel: 3.2.0-33 -> 3.5.0-17
arch: i686 + pae (32 bit) -> x86_64 (64 bit)

I don't know which one matters, but it's a subject for further
investigation.

пятница, 26 октября 2012 г., 1:48:50 UTC+7 пользователь Alexey Kupershtokh
написал:

It's probably glibc/VDSO changes. I wager that when you trace your
benchmark with `strace -c gettimeofday,clock_gettime`, you'll see a
ton of hits on your old system and hardly any on your new system.

Did you mean command strace -c -e "gettimeofday,clock_gettime" node 3.js ?

Old (on a more powerful desktop pc):
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

13220 wicked 20 0 2104 508 428 S 66 0.0 7:46.70 strace

13221 wicked 20 0 33144 9036 4136 R 41 0.1 4:42.47 node


wicked@wicked-desktop:~/Alawar$ time strace -c -e
"gettimeofday,clock_gettime" node 3.js
^C% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
100.00 0.799649 0 47083893 gettimeofday
0.00 0.000000 0 6 1 clock_gettime
------ ----------- ----------- --------- --------- ----------------
100.00 0.799649 47083899 1 total

real 22m28.796s
user 2m5.124s
sys 12m45.256s

As you can see I ctrl+c'ed the process after 22 minutes.

New (on a weaker laptop):
wicked@wnote:~$ time strace -c -e "gettimeofday,clock_gettime" node 3.js
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
-nan 0.000000 0 3 clock_gettime
------ ----------- ----------- --------- --------- ----------------
100.00 0.000000 3 total

real 0m8.761s
user 0m8.741s
sys 0m0.016s

The difference is obvious :)

понедельник, 29 октября 2012 г., 19:38:37 UTC+7 пользователь Ben Noordhuis
написал: