4 ms·

One other micro optimization for you. Assuming the length of the array does not change in the operation, this is usually faster: for (var j=0, len=input.l

One other micro optimization for you. Assuming the length of the array does not change in the operation, this is usually faster: for (var j=0, len=input.length; j < len; ++j) { This prevents rechecking the array length on every iteration.

throwaway_yy2Di 12y ago
I actually didn't get any speedup with that one -- looks like V8 can optimize that already. But you're right, that's an important one on some browsers. You can squeeze out another factor of 2 with typed arrays: var input_typed = new Uint32Array(input) exports['numeric typed array'] = function() { var acc = 0; for (var j=0; j<input_typed.length; ++j) { acc += input_typed[j]; } } ✓ Array::forEach() x 1,999,244 ops/sec ±2.93% (84 runs sampled) ✓ fast.forEach() x 5,161,137 ops/sec ±2.05% (85 runs sampled) ✓ explicit iteration x 27,851,200 ops/sec ±1.32% (86 runs sampled) ✓ explicit iteration w/precomputed array limit x 28,567,527 ops/sec ±1.33% (86 runs sampled) ✓ numeric typed array x 42,951,837 ops/sec ±0.97% (88 runs sampled) Winner is: numeric typed array (2048.40% faster) And probably more still if you can figure out the asm.js incantation that makes everything statically typed.
- WickyNilliams 12y ago
  The optimisation mentioned by the grandparent is specific to looping overso-called "live" collections of the DOM. NodeList [0] is sometimes a live collection, and is the return type of querySelectorAll, so it's likely you've dealt with this type of collection. The reason it incurs an overhead is because the DOM is traversed every single time the property is read, to ensure nothing has changed. You can see why caching the length is a reasonable optimisation, as you're unlikely to be modifying the collection while looping. [0] https://developer.mozilla.org/en/docs/Web/API/NodeList https://developer.mozilla.org/en/docs/Web/API/NodeList
  - BrandonLive 12y ago
    Exactly. Although, I am curious if there's a reason the JS engine (possibly working with the DOM implementation) can't optimize that to one look-up, if the JS in the loop doesn't change that part of the DOM or call anything that forces it to yield. I suspect a lot of the optimization opportunity in browsers today is less about JS or DOM in isolation but more about ways they could work together to improve situations like this one. (Note: I understand this one is solvable by a proficient/attentive developer, but not all developers are like that, and not all such DOM/JS transition problems are as easily solvable from your JS code)
nawitus 12y ago
The length is not recalculated on every pass. However it's slightly faster. http://stackoverflow.com/questions/17989270/for-loop-performance-storing-array-length-in-a-variable http://stackoverflow.com/questions/17989270/for-loop-perform...

throwaway_yy2Di 12y ago

I actually didn't get any speedup with that one -- looks like V8 can optimize that already. But you're right, that's an important one on some browsers. You can squeeze out another factor of 2 with typed arrays: var input_typed = new Uint32Array(input) exports['numeric typed array'] = function() { var acc = 0; for (var j=0; j<input_typed.length; ++j) { acc += input_typed[j]; } } ✓ Array::forEach() x 1,999,244 ops/sec ±2.93% (84 runs sampled) ✓ fast.forEach() x 5,161,137 ops/sec ±2.05% (85 runs sampled) ✓ explicit iteration x 27,851,200 ops/sec ±1.32% (86 runs sampled) ✓ explicit iteration w/precomputed array limit x 28,567,527 ops/sec ±1.33% (86 runs sampled) ✓ numeric typed array x 42,951,837 ops/sec ±0.97% (88 runs sampled) Winner is: numeric typed array (2048.40% faster) And probably more still if you can figure out the asm.js incantation that makes everything statically typed.

WickyNilliams 12y ago
The optimisation mentioned by the grandparent is specific to looping overso-called "live" collections of the DOM. NodeList [0] is sometimes a live collection, and is the return type of querySelectorAll, so it's likely you've dealt with this type of collection. The reason it incurs an overhead is because the DOM is traversed every single time the property is read, to ensure nothing has changed. You can see why caching the length is a reasonable optimisation, as you're unlikely to be modifying the collection while looping. [0] https://developer.mozilla.org/en/docs/Web/API/NodeList https://developer.mozilla.org/en/docs/Web/API/NodeList
- BrandonLive 12y ago
  Exactly. Although, I am curious if there's a reason the JS engine (possibly working with the DOM implementation) can't optimize that to one look-up, if the JS in the loop doesn't change that part of the DOM or call anything that forces it to yield. I suspect a lot of the optimization opportunity in browsers today is less about JS or DOM in isolation but more about ways they could work together to improve situations like this one. (Note: I understand this one is solvable by a proficient/attentive developer, but not all developers are like that, and not all such DOM/JS transition problems are as easily solvable from your JS code)

nawitus 12y ago

The length is not recalculated on every pass. However it's slightly faster. http://stackoverflow.com/questions/17989270/for-loop-performance-storing-array-length-in-a-variable http://stackoverflow.com/questions/17989270/for-loop-perform...