3 ms·
This is a very mediocre article that mixes some good advice with misleading and frankly bad things. Justifying forEach (which is several times slower than a fo
by gbuk2013 9y ago
This is a very mediocre article that mixes some good advice with misleading and frankly bad things.
Justifying forEach (which is several times slower than a for loop) with sparse arrays (which are an anti-pattern because they take you out of "fast elements" mode in V8 at least) is laughable in a sad way. It also has no "break" functionality , which is important if we are talking about performance (i.e. when iterating the array to find a specific member).
The advice for using array literals to insert elements is also bad for the similar reason that it makes it easy to create sparse arrays.
That and "i>arr.length" in the example means the for loop will run exactly 0 times! ;)
Using "filter", "map" and "reduce", by the way, is also slower than using a for loop, even if broken out into a separate function for purposes of chaining. This is because they call a function on each iteration and function calls (even with optimisation) are inherently more expensive. So, use them only when this difference in performance does not matter.
The closure / timer example is just so convoluted. Of course the closure will keep "bar" in scope - that's what closures do! The "foo" object doesn't somehow magically own "bar" it just has a reference to it, same as the closure. If something still references an object then GC will not touch it.
Similarly for the event listeners advice, which is also badly worded.
And if you do need to write a timeout-based loop, I respectfully suggest the following construct:
const interval = 1000;
var timer;
(function loop () {
... do stuff ...
timer = setTimeout(loop, interval);
}());
Now you can even use "rewire" to control the interval during your unit tests - bonus!
The Arrays vs Objects thing is just shallow. In reality, the advice is "it depends". If you need to iterate, use an Array. If you need to access by key, use an Object (or better a Map). If you need both (and this frequently happens in my experience) then you have to decide depending on the size of your structure.
- vanderZwan 9y agoThank you, you saved me the hassle of writing a very annoyed rant. Here's a performance tip: learn how to measure your damn code in the context of the website, because the JIT depends on heuristics that involve the context of the whole code. Open website -> Open Dev Tools -> Performance -> Do Stuff for a reasonable amount of time. Then you can actually reason about what causes the bottleneck based on the numbers. If you're on Chrome, you can even look at the source code after using the performance tab for a while, and see a line-by-line breakdown of where most of the time was spent, and find the hot path down to the individual expression or statement. Fix real bottlenecks, not hypothetical ones.
- sheetjs 9y ago> It also has no "break" functionality , which is important if we are talking about performance (i.e. when iterating the array to find a specific member). The article is woefully misinformed regarding `forEach` and I agree that the array methods in general are slower [1], but `some` will bail out on the first true value returned. To be sure: [1,2,3,4,5].some(function(n) { console.log(n); return n>=2; }); will not run the callback function after processing the 2 [1] https://news.ycombinator.com/item?id=7938173 https://news.ycombinator.com/item?id=7938173
- gbuk2013 9y ago"some" !== "forEach" ;) Also, "some" still has the performance penalty of an extra function call per iteration (as I know you know based on your linked comment) and we are talking about performance advice here. But good point - I've never actually used "some" before, so I learn something new today - thanks :)
- tkone 9y agothe latest versions of v8 (and others) have optimized the paths for calling these array functions and likely break down into for/while loops when they're jitted.