Echo JS 0.11.0

<~>
tracker1 2221 days ago. link 3 points ▲ ▼
While I agree that it's worth knowing these things.  In the end, use the clearest code as much as possible.  A quick reduce with an inline fat-arrow function is much shorter and easier to understand than passing off into another function that does a for loop, or worse inlining the loop.

I didn't downvote, but will suggest that one should optimize when one needs to optimize.  Also, one should use metrics to find real-world bottlenecks that are causing actual pain or stuttering.  In the end adding additional lines of code or making more complicated loops increases complexity and size, that also count.

In the end, write clean, concise code, with just enough comments to cover any possible confusion in logic or intent, and leave it at that unless or until you have metrics to properly point the blame.

In the end it depends on your use case and your need, and unless or until you *have* to improve performance, concentrate on clean code first.

Replies

harambe 2220 days ago. link 1 point ▲ ▼
You seem to have completely missed the part where the author said it was a real life scenario where he had to aggregate some data on a large dataset without making extra db calls. That’s exactly where you want to optimize for speed.
tracker1 2218 days ago. link 2 points ▲ ▼
I just don't want to encourage less experienced developers to prematurely optimize.

Also, calling them "Performance Mistakes You Should Stop Doing" is a bit of a red herring in this case.  As it isn't something you should stop doing unless you need to for performance reasons (after you've determined it's an issue).

There are a couple down-votes and I didn't want to leave the impression that I was one of them.