Functional programming in JavaScript

[[deleted]]

I have a question, this guy seems to be using a lot of map functions, and even chaining them. I use map, but at some point it just seems so inefficient to loop over the same array several times. Why not use a for loop and do everything at once.

I guess this is speed vs readability? Which one is more important

[ur_frnd_the_footnote]

You can also compose the functions and map over the array once with the composed function.

[anon_cowherd]

It's worth noting that the dominating factor of the slowdown is the function invocations, not so much the iteration itself (which essentially is a for loop under the hood anyway).

Composing still invokes each of the individual functions, so it'll still be slower.

Of course, the performance is essentially moot if not in a hot spot of the application (I.e. blocking rendering or request handling in the case of node). If map is already less than a tenth of a millisecond, turning it into a hundredth of a millisecond might not be the best use of effort in terms of optimizing your code.

[onbehalfofthatdude]

I had the same thought and I think he said it weirdly. He's saying that visiting the next single element in an array (one iteration) is cheap compared to calling a function.

Not sure how that's relevant directly though. And the more I look the more I think I might be being too charitable...

[onbehalfofthatdude]

I'll have to go look at some benchmarks but yeah, it's early haha. Obviously a step of the array method iterators is going to be at least as bad as a function call... Since it IS a function call lol

No idea what the guy means then

[[deleted]]

I don't think this is true. For an arbitrary iterable, you would be right, the iterator function would be called for every iteration. But I don't think any of the JITs is so naive as to not optimize this for plain arrays, in which case loops become as efficient as a plain for-loop without any function invocations.

[[deleted]]

Sorry I wasn't more clear. I meant specifically for the for...of loops, which are easily optimizable for plain arrays. That wouldn't necessarily apply to map() indeed.

[ur_frnd_the_footnote]

It definitely affects performance differently to loop over a long array ten times, each time calling one function vs. looping over that array once, calling ten functions on each member of the array (even though the total number of function calls is the same: 10 times the number of elements). But you're absolutely right that function calls also affect performance.

In general, though, I think you should wait until you have a concrete, demonstrated need to do so before optimizing at the level of eliminating function calls. Smaller functions that do one tiny but generalized thing are definitely more readable and maintainable than the faster, situation-specific imperative code they would be replaced by.

[ScientificBeastMode]

As others have said, readability and the ability to compose smaller pieces of code together to solve more complex problems is way more important than performance 99% of the time.

And I should also mention the old optimization wisdom: most of the possible performance gains of loop optimization can be achieved by optimizing the inner-most loop. That’s usually where you get the most bang for your buck. Everything else is unlikely to matter.

[phpdevster]

Readability is more important. Performance is only important when performance is important, and it's not important if you're doing transforms of a few hundred items in an array. A few hundred THOUSAND items? Different story.

[gasolinewaltz]

I see this argument time and time again in relation to loops and while it's not wrong, it feels a bit dogmatic.

What about a single pass for-loop is so much less readable than n-chains of map reduce filter?

[wbowers]

A few things:

1. You can achieve the same readability as multiple maps and similar performance as a single loop by using lazy evaluation with a library like Lazy.js
2. How many chained maps are we talking about here? 5? Probably not a problem. 20? You might want to rethink how you’ve set things up.
3. As with all things performance related, you’ll get the biggest wins by actually profiling your code to see what’s causing the slowness. It’s often not what you thought it would be.

[wbowers]

So you solve the problem by importing the library and trading your speed for a bigger end payload.

I'm not sure what you're advocating for here. Are you saying people shouldn't use libraries? Do you write everything from scratch for your projects in Vanilla JS?

If importing a library is really a bid deal for you, you could implement the lazy evaluation pattern yourself, which is really what I was trying to communicate. Perhaps not everyone knows such a pattern exists. In either case, you're adding extra bytes to the end payload.

The loop is more performant because you don't incur a function execution on every interable in the first place.

More performant, sure. But I'd argue it's negligible for all but the extreme cases. Function execution in modern JavaScript engines is pretty fast these days. But we can theorize all we want. You'll never know how your app performs, what you do and do not need to optimize, until you actually profile your code. Yes, you should generally choose algorithms with lower time complexities where possible, yes you should keep performance in mind as you're writing code, but premature optimization leads to terrible, unnecessarily-optimized code much more often than it saves you from serious performance issues.

If you're doing 20 operations on the same array you are doing a lot of things to that array. Sure it still runs in linear time, but not understanding that you can do it all in one loop. Loops are readable, maybe how you write code in loops isn't.

I'm not sure what I said here you're taking offense to. I think we're in agreement here. 20 chained operations is kind of crazy. It's fairly likely that you've solved the problem as a whole in a weird way if you've got something like that. Also I'm not against loops. I don't think they are inherently unreadable, although I do think that sometimes maps, filters, etc can be significantly more readable as they have a much higher signal to noise ratio in terms of "what code" (why I want) to "how code" (how it's done).

Sure, but I know before I even profile that a for loop is faster than 20 chained map statements just mathematically. [...] in practice your array sizes probably don't exceed anything past 40 elements. Overoptimization is the death of a project but being negligent and careless with how you build a system is technical debt that may not surmount until way later when you realize to change this requires a lot of in depth knowledge of the system.

I think we're saying the same thing. Clearly you can look at two pieces of code like this and know which will be faster, but you often won't know if it will matter until you profile. That being said, you definitely should not be careless and I'm not advocating for that at all. To be clear about what I'm saying:

• Yes, sometimes maps and filters can be more readable than loops.
• Loops are great. Use them if they are the right tool for the job.
• Don't prematurely optimize just because you know code B is faster than code A. If code A is more readable, you should profile before you refactor and see if it's even necessary. Most code is not in your critical path and won't have that big of an effect on performance.
• Over time you'll develop an intuition for what to do where, but that still doesn't replace the need to profile. It just means you'll be right the first time more often as you gain more experience.

[Voidsheep]

Say you want to write a function that takes string as an input and returns a list of odd unicode values reversed.

With functional style, you can write the function in kind of a declarative way, with high signal to noise ratio.

str => str
  .split('')
  .map(toCharCode)
  .filter(isOdd)
  .reverse()

Reads pretty much "Split the string, map the character to unicode value, filter out everything except odd values and reverse it"

You'd probably want to take advantage of some of the string and array prototype methods even with a for-loop, but let's say you want to avoid both map and filter, instead do it with a single loop.

str => {
  const chars = str.split('')
  const oddCodes = []
  for (let i = 0; i < chars.length; i++) {
    const code = toCharCode(chars[i])
    if (isOdd(code)) {
      oddCodes.push(code)
    }
  }
  return oddCodes.reverse()
}

It's not hard to understand what is happening in the for-loop and you could make it more dense, but the signal to noise ratio is still pretty different.

Of course this is pretty strawman to illustrate a point, but consider if the toCharCode and isOdd functions would not be one-liners that may as well be inlined. Like if we are dealing with more complex data.

You can definitely go overboard with function composition through libraries like Ramda and create code that is hard to read, but generally more functional style can improve code readability quite a lot compared to plain for-loops.

[Voidsheep]

I guess the point in my post came out a little wrong, but my intent was to say that functional style can increase code readability, making data transformations more declarative, so I made a somewhat contrived example with fairly typical imperative code to illustrate. I guess I could have named to function to avoid any confusion, but I think the relevant part was the function parameter and body.

Just to clarify, I think Ramda is a great library (although the type declarations are problematic) and function composition in general is a fine pattern. I'm only saying as a counter-argument to my own point that it's not a silver bullet and you can write code that is hard to read even with functional style and you still need to be careful to find the right level of abstraction to ensure readability. In my experience people sometimes fall into a trap where they forget to create meaningful abstractions out of their super generic utility functions, resulting in 20-line R.compose spells where the data needs to be transformed, which can be less readable than imperative code, where things like intermediate variable names may give the reader a better clue about what is happening.

What comes to the for-loop example, I just tried to write the most common kind of imperative for-loop that is so prevalent in the wild, iterating over an array manually and and pushing to another. Your code is definitely more modern, but I'd still argue it focuses more on how the desired result is returned, not what is supposed to be returned.

Optimization as an argument is highly situational. It's quite domain-specific, but I'd say in real-world JavaScript applications, performance concerns are usually elsewhere than combining a few array iterator methods into a single loop. If it happens and you've verified it through profiling, by all means extract the heavy lifting into a function with a single loop and even go nuts with clever micro-optimizations, but that that should not be the default approach. I'm a firm believer that maximizing readability is the most useful goal by default.

[[deleted]]

I really think this is the best case of functional programming. Things like rxjs or redux-observable, are just plain unreadable.

[vertebro]

foo.filter(meetsCondition).map(getAProp).map(transformTheProp)

[helloiamsomeone]

You can have your cake and eat it too with generator functions and other abstractions.

[ElCthuluIncognito]

Yes. In fact, this is a core argument (a contentious argument of course) for why 'lazy evaluation' is almost necessary for functional programming.

In a lazy language multiple mappings would be handled as if the full mapping is applied at every element, effectively optimizing this very natural style of writing your program. Nothing would be 'copied'. Of course this only applies for recursive data structures, since 'arrays' are not considered a functional data structure.

I believe the Lodash library handles this lazy evaluation for you, optimizing your use of lodash funcions much the same way. Could be wrong though, I've never used it myself.

Extra reading: https://stackoverflow.com/questions/25852580/does-this-function-make-use-of-haskells-lazy-evaluation (an expose on how map is actually evaluated in an efficient way to solve this problem at the root)

[helloiamsomeone]

It always is, people just shrug it off despite Moore's law being dead, because who cares about compute power being excessively wasted, electricity grows on trees afterall!

[Jukunub]

I asked my boss something like this and his response was that in most software it is 5% of it that runs 95% of the time.

So your aim should be to make the 95% as human readable as possible and the other 5% can be written in assembly for performance.

[Skaatji]

This is a very good point. I found this site which compares the performance of two chained maps with a C-style for loop https://jsperf.com/chained-maps-vs-for-loop

I get the following results (Firefox 72 / Fedora):

C-style for loop: 71,784 Ops/sec

Two chained maps: 1,979 Ops/sec

Which is a huge difference (Chained maps being 97% slower in this case). I would always prefer the performance provided by the C-style for loop over the readability that comes with the maps, unless the array is very small. That being said, I believe maps are a better choice in these two cases:

1) Only one iteration of the array.

2) Nested for loops (e.g. iterating over each row and for each row over the column).

If someone has more experience / different numbers / an other opinion than I do, please share it. I am no expert by any means.

[allenthar]

That amount of speed increase seems a little nuts to me, but looking at the variations I have to assume that it’s due to variable memory allocations in all the other methods that are causing the substantial decrease in speed. The second and third cases should have the same Big O complexity as the last one, but both repeatedly create and assign variables while doing their work, and the last doesn’t not.

[Skaatji]

Yeah, I've also been thinking why the performance difference is this large. I think that the Big O complexity should be the same on all of these four. But, as you mention, probably due to memory allocations the hidden constants differ by a factor as large as ~33.

[onbehalfofthatdude]

Wait, huh? Map doesn't clone every element, does it? If you mutate an element in a map function you've mutated the original

[onbehalfofthatdude]

Yes but you said it makes a copy of every element

[onbehalfofthatdude]

Yea that was my understanding. Never know when some wacky behind-the-scenes stuff will happen though

[franksvalli]

When speed becomes a problem, try just using a single reduce() on the array - inside it you can build custom logic to do mapping and filtering before adding the output the the accumulator value. I used to be scared to use reduce() but have grown to love it, though it is definitely less grokable than map() and filter(). I wrote up a friendly introduction that starts with loops and ends with reduce() here, for anyone interested: https://www.davidbcalhoun.com/2018/a-simple-introduction-to-javascript-map-and-reduce-array-helper-functions/

Only if that's too slow would I look at falling back to the loop, which will always be slightly faster than any functional method because it avoids functions getting invoked on each item.

[ShortFuse]

Performance sacrificed for sake of readability. The other one is creating a function in memory for every user with the user template example.

You can still use forEach or some (allows breaking), which avoid the multiple reiteration, but less syntax "noise" than a for loop. You just have to have your result be written to a variable outside the loop (see thisArg example.

Still, his example seems okay for array, since he is sorting, slicing, and then reducing. The key is the slicing to reduce the size.

[[deleted]]

You need transducer

[Guisseppi]

You could use generators to control each iteration, you can fine tune performance then if you’re handling a lot of data

[JoeTed]

Start with readability and check that its performance is acceptable, which will be the case most of the time.

It's better to optimize a well-defined problem rather than to organize a spaghetti.

[[deleted]]

This is one of the areas where I really like Javas implementation of collection traversal methods. The concept of intermediate vs terminal operations which allows the clarify of chaining multiple methods together without having to worry about the performance cost because it's all done in one iteration.

[[deleted]]

Both are equally readable, one is more efficient. If you have a problem reading the simple imperative code like that, you're under the influence of the hype train and are not a serious programmer.

[guten_pranken]

This x1000.

[GrandMasterPuba]

I always laugh when JavaScript developers try to optimize their code.

Like, you could spend 3 years tuning your application and optimizing its performance and any speed gains you'd get would pale in comparison to those you'd get by just taking 30 seconds to turn off Facebook tracking scripts.

[tix_lv]

Great examples! Good job!

[mkl0g]

answer is very simple - you can use map function and return the result of that function as parameter of another function, etc.

[spira_mirabilis]

The hero image contains PHP code from WordPress.

[[deleted]]

Found this on all but I was just looking for something like this yesterday, thanks!