3 ms·

I think you need the talk to be able to understand what they meant. Because I for one haven't heard any rumors that forEach is faster than a for loop for examp

I think you need the talk to be able to understand what they meant. Because I for one haven't heard any rumors that forEach is faster than a for loop for example, and a lot of the other stuff. There is also a lot of things that are true in certain browsers but not others, if you want the fastest possible performance you probably need to optimize per engine. (But that is overkill for most Javascript applications)

philbo 15y ago
Strongly agree. To me the majority of slides read like one big strawman, I didn't realise the myths were even myths. Or, in a couple of cases, what they attribute to performance concerns are things I'd attribute to good programming style for other reasons.
mistercow 15y ago
Well, `forEach` being faster than a for loop is more of a newbie misconception I think. It's not an unreasonable assumption, after all. In fact, looking at the `forEach` algorithm[1], it is not even immediately obvious why it would be so much slower than a for loop. It seems that the killer is the membership test[2] at line 44. What I don't really understand is why `i in O`, when O is an array, would be so slow, and furthermore, given that it is that slow, why `forEach` uses it instead of a simple bounds check. [1]: https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Array/forEach#Compatibility https://developer.mozilla.org/en/JavaScript/Reference/Global... [2]: http://jsperf.com/for-vs-foreach/17 http://jsperf.com/for-vs-foreach/17
jdd 15y ago
The point of this test is to show that by creating your own custom forEach-lite or other native-lite implementations you can get better performance over native. Many times you don't need to support all of the functionality/edge cases of the native method and that allows you to gain performance/custom-functionality and save code because you no longer need to have an ES5 compliant fallback. Many libs, like Underscore.js, fork for native methods but could reduce code/gain speed if they settled for simpler methods. Most devs don't care about supporting sparse arrays or ToUint32'ing a `length` value and this allows us to optimize for the common case. Also, by implementing a custom method you can gain functionality like exiting early by explicitly returning `false` or method chaining. http://jsperf.com/for-vs-array-foreach/4 http://jsperf.com/for-vs-array-foreach/4

philbo 15y ago

Strongly agree. To me the majority of slides read like one big strawman, I didn't realise the myths were even myths. Or, in a couple of cases, what they attribute to performance concerns are things I'd attribute to good programming style for other reasons.

mistercow 15y ago

Well, `forEach` being faster than a for loop is more of a newbie misconception I think. It's not an unreasonable assumption, after all. In fact, looking at the `forEach` algorithm[1], it is not even immediately obvious why it would be so much slower than a for loop. It seems that the killer is the membership test[2] at line 44. What I don't really understand is why `i in O`, when O is an array, would be so slow, and furthermore, given that it is that slow, why `forEach` uses it instead of a simple bounds check. [1]: https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Array/forEach#Compatibility https://developer.mozilla.org/en/JavaScript/Reference/Global... [2]: http://jsperf.com/for-vs-foreach/17 http://jsperf.com/for-vs-foreach/17

jdd 15y ago

The point of this test is to show that by creating your own custom forEach-lite or other native-lite implementations you can get better performance over native. Many times you don't need to support all of the functionality/edge cases of the native method and that allows you to gain performance/custom-functionality and save code because you no longer need to have an ES5 compliant fallback. Many libs, like Underscore.js, fork for native methods but could reduce code/gain speed if they settled for simpler methods. Most devs don't care about supporting sparse arrays or ToUint32'ing a `length` value and this allows us to optimize for the common case. Also, by implementing a custom method you can gain functionality like exiting early by explicitly returning `false` or method chaining. http://jsperf.com/for-vs-array-foreach/4 http://jsperf.com/for-vs-array-foreach/4