4 ms·

One point towards using Array prototype functions (map, filter, reduce, etc.), is that they are often much more readable. For loops are harder to skim. Still,

One point towards using Array prototype functions (map, filter, reduce, etc.), is that they are often much more readable. For loops are harder to skim. Still, I don't understand the for loop hate. I have seen people argue against 'pointless optimizations', in the name of readability. And while yeah, arr.filter().map() is probably faster to comprehend, you're still iterating through the array twice. Pointless optimizations, not so much when the array is thousands of elements long.

yxhuvud 9y ago
Iterating a long array twice to do two simple things can often be faster than iterating once to do a more complicated thing. See for example https://stackoverflow.com/questions/8547778/why-are-elementwise-additions-much-faster-in-separate-loops-than-in-a-combined-l https://stackoverflow.com/questions/8547778/why-are-elementw... . The wonders of modern processors and compilers.
- taeric 9y ago
  That link is more about the pitfalls of page alignment. Caches being a very dangerous topic. Getting the data aligned in a cache friendly way returns those loops to the expected behavior of one iteration being faster than two.
ComputerGuru 9y ago
I’ll never understand this. JavaScript’s threading model (none) makes it ridiculously easy to implement coroutines/iterables so that map, filter, and co can be efficiently written. How did Microsoft manage to realize the necessity of coroutined iterables in a threaded, impure, multiprocess-capable language like C# (without breaking backwards compatibility, might I add) with Linq, and yet JavaScript couldn’t? (If I may be permitted to go slightly off topic here, I also think it’s a damn shame Rust devs were so eager to release v1.0 of their shiny, new language to attract the masses that Rust - the language, not stdlib - shipped without native concepts to accommodate iterables and async/await. Unthinkable this side of 2010 for a language that aimed to be the second coming of C++).

yxhuvud 9y ago

Iterating a long array twice to do two simple things can often be faster than iterating once to do a more complicated thing. See for example https://stackoverflow.com/questions/8547778/why-are-elementwise-additions-much-faster-in-separate-loops-than-in-a-combined-l https://stackoverflow.com/questions/8547778/why-are-elementw... . The wonders of modern processors and compilers.

taeric 9y ago
That link is more about the pitfalls of page alignment. Caches being a very dangerous topic. Getting the data aligned in a cache friendly way returns those loops to the expected behavior of one iteration being faster than two.

ComputerGuru 9y ago

I’ll never understand this. JavaScript’s threading model (none) makes it ridiculously easy to implement coroutines/iterables so that map, filter, and co can be efficiently written. How did Microsoft manage to realize the necessity of coroutined iterables in a threaded, impure, multiprocess-capable language like C# (without breaking backwards compatibility, might I add) with Linq, and yet JavaScript couldn’t? (If I may be permitted to go slightly off topic here, I also think it’s a damn shame Rust devs were so eager to release v1.0 of their shiny, new language to attract the masses that Rust - the language, not stdlib - shipped without native concepts to accommodate iterables and async/await. Unthinkable this side of 2010 for a language that aimed to be the second coming of C++).