6 ms·
Much of both sides of this argument are opinion, but wrt this comment. > ... no function call overhead. This code has more function calls. O(n) vs 3 for the o
by tvier 2y ago
Much of both sides of this argument are opinion, but wrt this comment.
> ... no function call overhead.
This code has more function calls. O(n) vs 3 for the original
- deleted 2y ago[deleted]
- khaledh 2y agoThat's not true. The lambdas used in the functional version are each called once for every item in the list.
- stouset 2y agoNo sane optimizer is going to emit the functional code as a gajillion function calls.
- khaledh 2y agoTrue, but now you're relying on a specific implementation and optimization of the compiler, unless the language semantics explicitly say that lambdas will be inlined.
- stouset 2y agoThis is true of literally anything and everything your compiler emits. In practice the functional style is much easier to optimize to a far greater degree than the imperative style.
- tvier 2y agoThis is why you shouldn't get into arguments about performance on the internet without highly specified execution environments. I'm going to take my own advice and go back to work :)
- tvier 2y agoYeah, if you treat it as javascript vs python they're likely correct (I'm not that familiar with js). The article and original comment were about function vs imperative though, so I assumed half decent runtimes for both.
- Spivak 2y agoIt's not? How could that possibly work when the lambda could throw and it could throw on the nth invocation and your stack trace has to be correct? If I run this in the JS console I get two anonymous stack frames. The first being the console itself. [1, 2, 3].filter(x => [][0]())