Re:JavaScript Performance MythBusters (via jsPerf)
by jdd on Saturday March 17, 2012 @02:47PM
(#3717802)
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.
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