Have you ever realised that using a map followed by a filter, or vice versa, is quite common? Did you know that you could half the computation time...
For further actions, you may consider blocking this person and/or reporting abuse
Cool research! 👏
As you mention at the end you have to weigh up the pros and cons, I personally prefer readability over performance...
BTW you can even go beyond and implement almost all "array transform methods" (.map, .filter, .find, .every...) using reduce
Thank you Facundo.
I myself also prefer readability, but if the performance to be gained is great, then I would definitely reconsider. I don't think just because reduce in general uses more code, means that readability is lost.
The readability issue here, is that
map,filter, andreducecommunicate an intent. When you readmap, you know that it takes an array, maps each element of that array to a new value, and returns that new array. When you readfilter, you know that it takes an array and returns an array of all elements that satisfy a condition. When you readreduce, you know that it takes an array and returns a single value. Except, in this case, this single value is another array, containing some values that are derived from the original array and that satisfy a condition. It's not that it's just more code, it's that you're saying one thing and doing another.And if performance of this code is of concern, I'd chuck the whole thing in a for-loop anyway and eliminate all function calls.
For sure, I think one of the main concepts we as developers should apply is expressiveness, the how-to implementation should be hidden in its own function or method or chunk of code. For example, in this case, you can create a function called mapFilter and you could implement it whatever you like, with a for, a reduce, composing a map and filter (I personally would choose this one) and the caller is benefices when using the function which has a name that represents the intention.
Quite interesting! Do note though that these results could also be reduced (thanks, I'll be here all week) to 'one operation takes half as much time as two operations'.
Have you by any chance looked at how a classic for loop does in this test?
Good point! I just did that, and this is what I get:
Somehow, for me, the map-time takes about four times as long as the other functions (it's weird and I have no clue why), but the for-loop outperforms all others.
I appreciate this, and see the benefit to performance, but unless it's an actual issue I prefer to keep them separate. I only like using
reducefor something simple, because it gets unreadable very quickly.If you filter first (as you should always do, when possible) then map iterates over a smaller array.
Others have already mentioned readability. But composition is also important: sometimes you already have the mapping and filtering functions somewhere and they are used in different contexts, so you just pass them to map and filter. Of course you can still implement a reduce that calls the mapping and filtering functions, but we go back to readability.
This seems like a useful trick when you need to filter and map over enormous arrays, but as a general guideline I would keep the mapping and filtering functions separate for readability and comparability (if that's even a word).
Maybe some day Javascript will have lazily evaluated streams and then this discussion will be moot.
Excellent breakdown. Thank you for your detailed approach to this! Bookmarking this for sure.
Thanks Ted, I appreciate that
Great to hear, I am glad it helped 👌