In FF it also slower. Would you know why? Unknown types for first iteration? I found that, because I was reducing an array of ints and and I was missing a check on the first item of the array.
I suspect you ended up measuring the cost of dispatching (starting) .reduce().
For example you can see a similar effect if you measure the startup time of sh compared to bash:
alex@quatermain:~$ time (I=1000; while [ $I -gt 0 ]; do I=$((I-1)); /bin/sh -c ''; done)
real 0m0.480s
user 0m0.375s
sys 0m0.136s
alex@quatermain:~$ time (I=1000; while [ $I -gt 0 ]; do I=$((I-1)); /bin/bash -c ''; done)
real 0m0.795s
user 0m0.634s
sys 0m0.199s
You may have observed is that on a particular browser the first call costs say 0.1ms of CPU time for a valueless start and remaining iterations cost 0.2ms as they of course internally are passing a value.
For small arrays that saving of 0.1ms might look substantial, for larger ones it just vanishes.
Not really sure the value in stating ‘I got 10% faster’ in a (single?) unspecified browser reducing over an array containing four integers is.
I just ran the JSperf test on my phone (Android 6, Chrome 59) and valueless is 6% slower.
In FF it also slower. Would you know why? Unknown types for first iteration? I found that, because I was reducing an array of ints and and I was missing a check on the first item of the array.
I suspect you ended up measuring the cost of dispatching (starting)
.reduce().For example you can see a similar effect if you measure the startup time of
shcompared tobash:You may have observed is that on a particular browser the first call costs say 0.1ms of CPU time for a valueless start and remaining iterations cost 0.2ms as they of course internally are passing a value.
For small arrays that saving of 0.1ms might look substantial, for larger ones it just vanishes.
Yes, thank you. It makes sense.
With 10000 items in the array the difference is almost null.