I was reading Death of for-loop article, and I thought maybe I should timeit the codes. I created this benchmark at jsperf which clearly shows that map-filter approach is about 90% slower.

So, why is FP code here is slower? and also, why be functional if it is slower?

The author was only talking about readability when it comes to FP and not efficiency or other execution factors when in real world, they are the preferred parameters.

Rephrasing, What are the real world factors to use functional programming apart from readability?

Pardon me for being lazy before. I am not really a writer and have trouble expressing my thoughts in written form.

Added: I found this MPJ Video which I also found to be helpful.

  • 1
    Your benchmarks are way too short to give any meaningful results. You should study how to write proper benchmarks, read some of Cliff Click's articles on benchmarking. – Jörg W Mittag Jan 26 '17 at 18:14
  • 2
    In your code you're doing almost no meaningful work. When the actual work you're doing is practically instantaneous then even a very, very small overhead can become a notable percentage of the time spent. That doesn't change the fact that it's a very, very small overhead, and is likely to be completely dwarfed by the productive work in cases where you actually have a lot of productive work to do (which tends to be when you actually care about performance). – Servy Jan 26 '17 at 19:06
  • 1
    Please avoid the strikeouts. They do not add to the clarity of the question and, in fact, markedly detract from it. If you want to remove material from your question, simply edit it out. If you're trying to show edit history, everyone can see that already here: softwareengineering.stackexchange.com/posts/340980/revisions – Robert Harvey Jan 26 '17 at 19:13
  • 1
    In general, I'd repeat Donald Knuth's idea that efficiency of a particular fragment does not matter for the overall efficiency 99% of time. No optimization makes sense before profiling. Preferring readability to CPU / RAM efficiency helps correctness and development speed. Having a fast program that crashes randomly is often less preferable than having a slower but very reliable program. – 9000 Jan 26 '17 at 21:07
  • 2
    90% slower doesn't matter when you can safely parallelize the work across 16 cores... – RubberDuck Jan 26 '17 at 22:37

As a few people already explained in the comments, the way you did your benchmarks make them irrelevant. If, however, there was an actual benchmark showing that the functional variant was indeed slower, then keep reading.

The author was only talking about readability when it comes to FP and not efficiency or other execution factors when in real world, they are the preferred parameters.

That's not quite right.

In real world, for most applications, a few microseconds you can optimize for a task performed by a user ten times per day doesn't mean much. Actually, it doesn't mean anything. In other words, such optimization is completely irrelevant for your product.

However, the time you spend:

  • Optimizing,
  • Reading code which is unreadable,
  • Fixing unreadable code which had bugs in it, because of its unreadability,
  • Fixing the bugs you introduced in an unreadable code

leads to hours, days, weeks and months of additional work, which translates directly to thousands of dollars wasted making and maintaining the product in the first place.

Therefore, readability is the preferred parameter in the real world, because there is real money involved there.

  • Thank you. It makes sense. I added a proper benchmark link in my edited post. – Harsh Gupta Jan 26 '17 at 19:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.