[PATCH]: Replace Array.prototype.slice.call()s 9-ish times faster
tjholowaychuk
traffic areas IMO
http://github.com/visionmedia/node/commit/9f1ae286b00e75ee6b4c8b0bd9a356dc4a61e118.patch
bench output:
toArray()
Raw:
> 10881.11888111888
> 10466.533466533467
> 10475.524475524475
> 10812.187812187813
> 10606.393606393607
Average (mean) 10648.351648351647
slice
Raw:
> 1149.8501498501498
> 1127.872127872128
> 1174.8251748251748
> 1167.832167832168
> 1165.8341658341658
Average (mean) 1157.2427572427573
Winner: toArray()
Compared with next highest (slice), it's:
89.13% faster
9.2 times as fast
1 order(s) of magnitude faster
Scott González
var slice = Array.prototype.slice;
slice.call(arguments, 1);
There's a chance the speed difference is from property lookups.
--
You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com.
To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
tjholowaychuk
benchmarking /Users/tj/Testing/js/benchmarks/toArray-vs-slice
Please be patient.
Scores: (bigger is better)
toArray()
Raw:
> 10489.510489510489
> 10613.386613386614
> 10560.439560439561
Average (mean) 10554.445554445554
args.slice()
Raw:
> 906.0939060939061
> 966.0678642714571
> 981.018981018981
Average (mean) 951.060250461448
slice.call()
Raw:
> 954.0459540459541
> 933.0669330669331
> 936.127744510978
Average (mean) 941.0802105412885
Array.prototype.slice.call()
Raw:
> 931.1377245508982
> 926.073926073926
> 919.0809190809191
function toArray(obj){
var arr = [];
for (var i = 0, len = obj.length; i < len; ++i) {
arr.push(obj[i]);
}
return arr;
}
var args = (function(){ return arguments; })('foo', 'bar', 'baz');
var slice = Array.prototype.slice;
args.slice = slice;
exports.compare = {
'toArray()': function(){
toArray(args);
},
'Array.prototype.slice.call()': function(){
Array.prototype.slice.call(args);
},
'slice.call()': function(){
slice.call(args);
},
'args.slice()': function(){
args.slice();
}
}
Average (mean) 925.4308565685811
Winner: toArray()
Compared with next highest (args.slice()), it's:
90.99% faster
11.1 times as fast
91.23% faster
11.4 times as fast
> Did you do any testing with:
>
> var slice = Array.prototype.slice;
> slice.call(arguments, 1);
>
> There's a chance the speed difference is from property lookups.
>
>
>
>
> > Small seemingly pointless optimization, but in some pretty high
> > traffic areas IMO
>
> > .
Scott González
To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
tjholowaychuk
toArray() push
Raw:
> 10925.074925074925
> 10928.071928071928
Average (mean) 10926.573426573426
toArray() []
Raw:
> 7716.283716283716
> 7890.10989010989
Average (mean) 7803.196803196803
On Jun 30, 10:42 am, Scott González <scott.gonza...@gmail.com> wrote:
> Interesting. Have you compared arr[i] = obj[i] to arr.push(obj[i])?
>
Isaac Schlueter
so much faster than a single slice.
Can you bench it against this implementation? I'm curious.
function toArray (args) {
var arr = []
arr.push.apply(arr, args)
return arr
}
I suspect that the overhead of Function#apply will be lower if the
list is long, but higher if the list is short. Since you're testing
with 3 elements (which is a pretty representative use-case) the loop
may be better.
--i
> To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
tjholowaychuk
this so I
figured I would see if node was using array slice. heres the results
for that implementation
toArray() push
Raw:
> 10924.075924075923
> 10677.322677322678
Average (mean) 10800.6993006993
toArray() push apply
Raw:
> 9344.655344655344
> 9240.75924075924
Average (mean) 9292.707292707291
Isaac Schlueter
this patch? If it's 10 times faster at doing something that's only
0.1% of the time spent, then that's probably not a worthwhile speedup,
but if you're seeing relevant effects in connect, then that's
interesting.
Guillermo Rauch
Guillermo Rauch
http://devthought.com
Isaac Schlueter
a real use case.
Usually, a simple web server getting slammed by ab is used as the benchmark.
tjholowaychuk
might not be
worth the change
On Jun 30, 11:47 am, Isaac Schlueter <i...@izs.me> wrote:
> Well, right, but the question is just how high-traffic that area is in
> a real use case.
>
> Usually, a simple web server getting slammed by ab is used as the benchmark.
>
>
>
> On Wed, Jun 30, 2010 at 11:41, Guillermo Rauch <rau...@gmail.com> wrote:
> > Isn't that the first thing he said?
> > "Small seemingly pointless optimization, but in some pretty high traffic
> > areas IMO"
>
> > On Wed, Jun 30, 2010 at 11:38 AM, Isaac Schlueter <i...@izs.me> wrote:
>
> >> Any idea what the impact is on a "hello world" server in node with
> >> this patch? If it's 10 times faster at doing something that's only
> >> 0.1% of the time spent, then that's probably not a worthwhile speedup,
> >> but if you're seeing relevant effects in connect, then that's
> >> interesting.
>
Erik Corry
store for the array the right size so it doesn't have to grow it as
you add stuff. Also it sets the length to the final value immediately
instead of updating it on every write.
2010/6/30 tjholowaychuk <tjholo...@gmail.com>:
> To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
Marco Rogers
performance considerations.
I would like to see the results of running the test with a larger
argument set. I realize that's not relevant for the proposed patch
because functions usually have a small number of arguments. But I'm
really confused about why the native slice function isn't faster and
why push is faster than index assignment.
On the other hand, I am glad to see that the prototype lookup for
Array.prototype.slice doesn't add very much overhead.
:Marco
On Jun 30, 2:41 pm, Guillermo Rauch <rau...@gmail.com> wrote:
> Isn't that the first thing he said?
> "Small seemingly pointless optimization, but in some pretty high traffic
> areas IMO"
>
>
>
>
>
> On Wed, Jun 30, 2010 at 11:38 AM, Isaac Schlueter <i...@izs.me> wrote:
> > Any idea what the impact is on a "hello world" server in node with
> > this patch? If it's 10 times faster at doing something that's only
> > 0.1% of the time spent, then that's probably not a worthwhile speedup,
> > but if you're seeing relevant effects in connect, then that's
> > interesting.
>
tjholowaychuk
app but an optimization is an optimization I suppose. ab is being
extremely clunky today but with HEAD vs this patch I seem to
consistently be
gaining ~200 rps
tjholowaychuk
var arr = new Array(args.length);
for (var i = 0, len = args.length; i < len; ++i) {
arr[i] = args[i];
}
return arr
is 1.5 times faster than my initial implementation, and 16 times
faster than Array.prototype.slice.call
Erik Corry
> This thread is really abusing my assumptions about javascript
> performance considerations.
Mine too, and I wrote Array.prototype.slice :-)
One reason could be that the Array.prototype.slice spec requires you
to treat undefined properties in the source array differently from
properties that are present, but contain 'undefined'. If the source
array has lots of uninitialized slots this will slow you down a lot.
Another reason could be a bug in the fast version :-).
> To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
tjholowaychuk
On Jun 30, 12:13 pm, Erik Corry <erik.co...@gmail.com> wrote:
> 2010/6/30 Marco Rogers <marco.rog...@gmail.com>:
Erik Corry
> ah! we have a winner
>
> var arr = new Array(args.length);
> for (var i = 0, len = args.length; i < len; ++i) {
Put args.length in a local?
> To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
Chris Winberry
Any faster if args.length is saved to a var first?
On Jun 30, 2010 3:13 PM, "tjholowaychuk" <tjholo...@gmail.com> wrote:
ah! we have a winner
var arr = new Array(args.length);
for (var i = 0, len = args.length; i < len; ++i) {
arr[i] = args[i];
}
return arr
is 1.5 times faster than my initial implementation, and 16 times
faster than Array.prototype.slice.call
On Jun 30, 12:03 pm, Marco Rogers <marco.rog...@gmail.com> wrote:
> This thread is really abusing m...
tjholowaychuk
but it should not be accessed twice
On Jun 30, 12:23 pm, Chris Winberry <cpt.obvi...@gmail.com> wrote:
> Any faster if args.length is saved to a var first?
>
Jan Schütze
var args_length = args.length;
var arr = new Array(args_length);
for (var i = 0, len = args_length; i < len; ++i) {
arr[i] = args[i];
}
return arr;
If anyone is interested in speed of loops in javascript, see:
http://blogs.sun.com/greimer/entry/best_way_to_code_a
Kind regards,
Jan
--
Joe Developer
tjholowaychuk
as while(n--)
On Jun 30, 3:11 pm, Joe Developer <joe.d.develo...@gmail.com> wrote:
> Why don't you try forEach rather than a for loop ? :)
>
>
>
> > Would be interested in results of this, too!
>
> > var args_length = args.length;
> > var arr = new Array(args_length);
> > for (var i = 0, len = args_length; i < len; ++i) {
> > arr[i] = args[i];
> > }
> > return arr;
>
> > If anyone is interested in speed of loops in javascript, see:
> >http://blogs.sun.com/greimer/entry/best_way_to_code_a
>
> > Kind regards,
> > Jan
>
> > > 2010/6/30 tjholowaychuk <tjholoway...@gmail.com>:
>
> > >>> > > >> >> > .
> > >>> > > >> >> > For more options, visit this group at
> > >>> > > >> >> >http://groups.google.com/group/nodejs?hl=en.
>
> > >>> > > >> > --
> > >>> > > >> > You received this message because you are subscribed to the
> > >>> > > Groups "nodejs" group.
> > >>> > > >> > To post to this group, send email to nod...@googlegroups.com.
> > >>> > > >> > To unsubscribe from this group, send email to
> > >>> > > nodejs+un...@googlegroups.com<nodejs%2Bunsu...@googlegroups.com>
> > <nodejs%2Bunsu...@googlegroups.com<nodejs%252Bunsubscribe@googlegroups. com>
>
> > >>> > > .
> > >>> > > groups.google.com/group/nodejs?hl=en.
>
> > >>> > > > --
> > >>> > > > You received this message because you are subscribed to the
> > Google Groups
> > >>> > > "nodejs" group.
> > >>> > > > To post to this group, send email to nod...@googlegroups.com.
> > >>> > > > To unsubscribe from this group, send email to
> > >>> > > nodejs+un...@googlegroups.com<nodejs%2Bunsu...@googlegroups.com>
>
> > >>> > > .
> > >>> > > > For more options, visit this group at
> > >>> > >http://groups.google.com/group/nodejs?hl=en.
>
> > >>> > > --
> > >>> > > You received this message because you are subscribed to the Google
> > Groups
> > >>> > > "nodejs" group.
> > >>> > > To post to this group, send email to nod...@googlegroups.com.
> > >>> > > To unsubscribe from this group, send email to
>
>
> read more »
Joe Developer
really? forEach() would be slow... cached for loop is nearly the same
as while(n--)
To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
Joe Developer
On Thu, Jul 1, 2010 at 5:36 AM, tjholowaychuk <tjholo...@gmail.com> wrote:really? forEach() would be slow... cached for loop is nearly the same
as while(n--)I think that V8 takes the native forEach 'inside', which benchmarking script are you guys using?
Karl Guertin
> really? forEach() would be slow... cached for loop is nearly the same
> as while(n--)
I haven't tested this construct, but I did comparison in
December/January between:
for(var i = 0, ii = arry.length; i < ii; i++){/*...*/}
and
for(var i = arry.length - 1; i >= 0 ; i--){/*...*/}
The first was several times faster, so I assumed it was caught and
fast pathed while the second construct wasn't. Not sure if this is
still true or not.
tjholowaychuk
of function calls with forEach()
On Jun 30, 3:40 pm, Joe Developer <joe.d.develo...@gmail.com> wrote:
> On Thu, Jul 1, 2010 at 5:38 AM, Joe Developer <joe.d.develo...@gmail.com>wrote:
>
> read more »
Marco Rogers
Essential forEach gets turned into the equivalent of a for loop.
Don't know if that's true, but that's how I read the statement. But
I'm sure there are time where v8 can't make that optimization.
Depends on the free variables involved and where else the function
passed to forEach is used.
Also have you tried this latest variant with arr.push? It's still
blowing my mind that that was faster than the index assignment. Maybe
that was a strange fluke of the previous implementations and this will
show different results.
:Marco
>
> read more »
Joe Developer
I think he's saying that the body of the function gets inlined.
Essential forEach gets turned into the equivalent of a for loop.
Don't know if that's true, but that's how I read the statement. But
I'm sure there are time where v8 can't make that optimization.
Depends on the free variables involved and where else the function
passed to forEach is used.
Also have you tried this latest variant with arr.push? It's still
blowing my mind that that was faster than the index assignment. Maybe
that was a strange fluke of the previous implementations and this will
show different results.
> ...
>
> read more »
--
You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com.
tjholowaychuk
On Jun 30, 3:40 pm, Joe Developer <joe.d.develo...@gmail.com> wrote:
> On Thu, Jul 1, 2010 at 5:38 AM, Joe Developer <joe.d.develo...@gmail.com>wrote:
>
> read more »
Erik Corry
>
>
> On Thu, Jul 1, 2010 at 6:12 AM, Marco Rogers <marco....@gmail.com> wrote:
>>
>> I think he's saying that the body of the function gets inlined.
>> Essential forEach gets turned into the equivalent of a for loop.
Nope. You have to remember that the programmer at any time can write
Array.prototype.forEach = function() { // funky stuff }. The inlined
version would then have to be magically out-of-lined for subsequent
calls. We can't do that.
What's happening here is that the loop variable and all the other
variables in the classic case are variables on the global object.
It's not a local variable because you are not inside a function.
Being inside {} doesn't do it.
Global variables are properties of a big hash map (the global object).
We've done a lot to optimize that, but at the end of the day it's
still a lot faster to have a local variable in the function that can
be register allocated. So that slows down the classic version a lot.
The forEach version is being slowed down by having a function call in
the inner loop. Apparently that is even more expensive than having
globals as your variables.
>
> Chrome (5.0.342.9 beta)
> classic: 23370
> forEach : 773
> I am a bit at a loss to explain this discrepancy
This is strange and I can't reproduce it with my version of Chrome 5.
Is the above code the only thing on the page or have you added jQuery
or something? Having a DOM object called 'i' might cause that sort of
slowdown since they are on the global object like the i variable.
Erik Corry
test the speed of array copying with a loop and with slice. Slice
wins hands down, as it should. This is especially noticeable if you
have holes in your array (not yet initialized, so the prototype shines
through). Consider.
var a = new Array(10);
Array.prototype[5] = 42;
a[5]; // Is 42. Checking for this is slow.
I'm not sure why your test is giving a different result.
Here is the entire text of my benchmark:
function using_loop(a) {
for (var i = 0; i < 1000; i++) {
var len = a.length;
var b = new Array(len);
for (var j = 0; j < len; j++) {
b[j] = a[j];
}
}
}
function using_slice(a) {
for (var i = 0; i < 1000; i++) {
var b = a.slice(0);
}
}
function benchmark_with_zeros(fun) {
var a = new Array(100);
for (var i = 0; i < 100; i++) {
a[i] = 0;
}
fun(a);
}
function benchmark_with_holes(fun) {
var a = new Array(100);
fun(a);
}
function benchmark_with_oldspace_objects(fun) {
var a = new Array(100);
for (var i = 0; i < 100; i++) {
a[i] = true;
}
fun(a);
}
function benchmark_with_newspace_objects(fun) {
var a = new Array(100);
for (var i = 0; i < 100; i++) {
a[i] = i + 0.2;
}
fun(a);
}
function variant(name, initializer, do_copy) {
var elapsed = 0;
var start = new Date();
for (var n = 0; elapsed < 2000; n++) {
initializer(do_copy);
elapsed = new Date() - start;
}
print('Time (' + name + '): ' + Math.floor(1000 * elapsed/n) + ' us.');
}
variant("loop-zeros", benchmark_with_zeros, using_loop);
variant("loop-oldspace", benchmark_with_oldspace_objects, using_loop);
variant("loop-newspace", benchmark_with_newspace_objects, using_loop);
variant("loop-holes", benchmark_with_holes, using_loop);
variant("slice-zeros", benchmark_with_zeros, using_slice);
variant("slice-oldspace", benchmark_with_oldspace_objects, using_slice);
variant("slice-newspace", benchmark_with_newspace_objects, using_slice);
variant("slice-holes", benchmark_with_holes, using_slice);
2010/6/30 tjholowaychuk <tjholo...@gmail.com>:
> --
> You received this message because you are subscribed to the Google Groups "nodejs" group.
> To post to this group, send email to nod...@googlegroups.com.
> To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
Isaac Schlueter
> What's happening here is that the loop variable and all the other
> variables in the classic case are variables on the global object.
> It's not a local variable because you are not inside a function.
In NodeJS, all modules are executed "inside a function", all the time.
--i