3 ms·
I didn't realize map-reduce was so much slower than a regular looped multiplication, regardless of the hardware the code was running on.
by shantara 5y ago
I didn't realize map-reduce was so much slower than a regular looped multiplication, regardless of the hardware the code was running on.
- zozbot234 5y agoYes, that was weird for a language with such a high focus on performance. My guess is that the compiler couldn't inline the "idiomatic" operations and had to fall back on generic implementations, which will be painfully slow in Swift due to the overhead of being ABI independent. You could do all this in other languages too, but it wouldn't be the "idiomatic" choice during development; it would be clear that you're giving up on performance for the sake of flexibility.
- ChrisMarshallNY 5y agoI suspect that, for most cases, it won’t matter (not everything needs to be optimized -heresy, I know). But for some “inner loop” stuff, it could make a big difference. Another issue, is that visitors will hit the entire set; even when it is no longer necessary to continue. We can do some tricks to make subsequent visits shorter, but they’ll happen, nonetheless. This always bothers me.
- viktorcode 5y agoIt isn't slower per se. The 'idiomatic' and imperative part aren't equivalent; 'idiomatic' performs unnecessary work. The real problem is the existence of the overhead isn't obvious from the code.
- hajile 5y agoThat's an implementation detail. Consider JS. The builtin implementation is naive and chaining calls results in multiple passes over the array. Lodash is different. It uses an iterator internally, so chaining isn't much of a performance difference (just the overhead of the function calls which are probably inlined by most JITs anyway). I see no reason why Swift couldn't (or shouldn't) do this in a future version.