3 ms·

Native methods can be slower than simply using a for (Edit: while) loop: http://allyoucanleet.com/post/21624742336/jsconf-us-12-slides http://allyoucanleet.com

by leokun 13y ago

Native methods can be slower than simply using a for (Edit: while) loop: http://allyoucanleet.com/post/21624742336/jsconf-us-12-slides http://allyoucanleet.com/post/21624742336/jsconf-us-12-slide... self = this is error prone because it relies on JavaScript's lexical scope to share a variable across nested functions. It's a gross abuse of closures. It invalidates the ability to bind or use apply later, since everything is bound to that local variable self, and it's simply not needed and is probably used to avoid considerable use of bind, but using bind is only an issue when you write flock of seagull style nested function code. using self = this is not the right solution, writing more modular code with smaller functions is.

sorich87 13y ago
Neither underscore nor lodash use a for loop. Both use the native Object.keys when available. underscore uses native Array#forEach and lodash uses a while loop. So only lodash forEach is actually faster. lodash is the only one to be performance focused. underscore always uses the native methods when possible.
jkrems 13y ago
Actually ran this on Chrome/V8 and the native method was faster. And as someone else wrote: lodash/underscore should normally fall back to the native methods if available. As for bind - funny that you mention that as a good alternative to using self/closure. Because while it is convenient and powerful, it's also slower than using self/closure. I don't want to pretend that for either `[].forEach` or `bind` the differences in speed are (in most cases) really that relevant, I just found your argumentation a little confusing here. As for bind vs. closure-self I wouldn't say that either is really better than the other. Both are perfectly fine options. The former is a pretty heavy solution (since it's basically using a special case of partial application) and can be confusing (e.g. calling `a.b()` can have weird behavior even when the implementation of b is known). The latter is less powerful but a little more explicit imho - you really see the this-scope expansion and it's not hidden away. Both solutions obviously can't protect you from "flock of seagull style nested function code" but as you wrote: that's not a problem of the way someones does this-binding, it's a problem with the design.
kevincennis 13y ago
I think whatever performance cost might exist with Object.keys and Array#forEach vs loops is outweighed in most cases by a pretty significant increase in readability. There are exceptions, of course, but I think the performance card gets played too often in cases where the difference is negligible. As for self = this, I tend to agree that it's kind of gross in most cases. It's not something I use very often. But unless you're willing to say that you're never going to use anonymous functions, the reality is that sometimes it's useful.
ricardobeat 13y ago
The performance hit of using .bind() instead of `self = this` is much larger than .forEach() vs loop. Pick your side :)
- leokun 13y ago
  I pick less chance for errors over performance. Referencing variables outside of local scope is something I avoid. Write beautiful code first, because it's easier to optimize beautiful code than to beautify optimized code.

by leokun 13y ago

sorich87 13y ago

Neither underscore nor lodash use a for loop. Both use the native Object.keys when available. underscore uses native Array#forEach and lodash uses a while loop. So only lodash forEach is actually faster. lodash is the only one to be performance focused. underscore always uses the native methods when possible.

jkrems 13y ago

Actually ran this on Chrome/V8 and the native method was faster. And as someone else wrote: lodash/underscore should normally fall back to the native methods if available. As for bind - funny that you mention that as a good alternative to using self/closure. Because while it is convenient and powerful, it's also slower than using self/closure. I don't want to pretend that for either `[].forEach` or `bind` the differences in speed are (in most cases) really that relevant, I just found your argumentation a little confusing here. As for bind vs. closure-self I wouldn't say that either is really better than the other. Both are perfectly fine options. The former is a pretty heavy solution (since it's basically using a special case of partial application) and can be confusing (e.g. calling `a.b()` can have weird behavior even when the implementation of b is known). The latter is less powerful but a little more explicit imho - you really see the this-scope expansion and it's not hidden away. Both solutions obviously can't protect you from "flock of seagull style nested function code" but as you wrote: that's not a problem of the way someones does this-binding, it's a problem with the design.

kevincennis 13y ago

I think whatever performance cost might exist with Object.keys and Array#forEach vs loops is outweighed in most cases by a pretty significant increase in readability. There are exceptions, of course, but I think the performance card gets played too often in cases where the difference is negligible. As for self = this, I tend to agree that it's kind of gross in most cases. It's not something I use very often. But unless you're willing to say that you're never going to use anonymous functions, the reality is that sometimes it's useful.

ricardobeat 13y ago

The performance hit of using .bind() instead of `self = this` is much larger than .forEach() vs loop. Pick your side :)

leokun 13y ago
I pick less chance for errors over performance. Referencing variables outside of local scope is something I avoid. Write beautiful code first, because it's easier to optimize beautiful code than to beautify optimized code.