I found a little time to run a number of tests, but I don't have time
now to analyze them. Anyone interested in seeing the raw data from
JSLitmus tests in five browsers running against lists with 10, 100,
1000, and 10000 elements can see my results, and run their own tests
here:
http://scott.sauyet.com/Javascript/Test/LoopTimer/3/
Note that FF seems extremely inconsistent, which makes me worry about
how it's interacting with JSLitmus. The runs shown here seem fairly
representative, though. All the other browsers seem fairly
consistent. The raw data (as a PHP array) is here:
http://scott.sauyet.com/Javascript/Test/LoopTimer/3/results.phps
If your intention is to time with accuracy what comes inside the for
loop, you ought to set library.length to a (much) big(ger) number: you
want the time spent inside the loop to be as close to 100% of the
total time as possible. Iterating a million times over the whole thing
with a badly chosen (small) library.length won't give you any added
accuracy in this regard.
That's why, for example, in the Safari row, you get these completely
different results:
library.length: 10 (items) 10k (items)
pushLookupIncrement: 375,6k 537
pushNewVarIncrement: 622,6k (1,65x) 1.3k (2,42x)
For the faster is the loop is, the bigger the % of error that a small
library.length introduces.
Also, looping through 10000 items, ought to take ~ 1000 times as long
as looping through 10 items, and that's not what your results show:
622,6k !== 1.3k*1000. That's too due to the error I'm talking of: the
10k items result is more accurate and the 10 items figure is off by
100-(622,6/13)= a 52.1% (an error quite big !, the real figure for 10
items was more than 2x that !)
And, as the loop of each tested f() takes a different amount of time
to execute, it's getting a different % of error... (That's the reason
why there's a JSLitmusMultiplier in my (modified) JSLitmus.js)