Hacker News Reader

Comment by sheetjs | Hacker News Reader

Premature optimization is the root of all evil -- Knuth

V8 has excellent profiling tools (exposed in chrome and in nodejs) which should be used first before considering fallbacks. Before seeking a third party library, be sure to check if the function is called many times or is taking a long time.

For example, I found that throwing map out and using a straight array (avoiding the function calls entirely) can be up to 50% faster than using the functional suspects. But that, in the eyes of some people, unnecessarily adds complexity to the code and may not be worth changing

View on HN

> Premature optimization is the root of all evil -- Knuth

HN should have a bot that posts the full quote whenever this line is cited since it's so often abused.

"There is no doubt that the grail of efficiency leads to abuse. Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.

Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified."

Plus who said it was / should be used prematurely anyway?

> Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs

Isn't that essentially what I described? "Before seeking a third party library, be sure to check if the function is called many times or is taking a long time."

On the issue of this particular library: The problem is that you can do much much better by avoiding map, forEach and friends. The overhead of the function calls can be completely avoided by using a direct for loop at the callsite.

So yes, you may find it slightly faster to use this library rather than the native map, but with a small redesign you can avoid map entirely and get a massive performance win.

Swap to use a slightly faster function someone else already wrote, or rewrite your code. Seems like the latter is more guilty of premature optimisation if this library is fast enough for the particular use.

I think it's a bit unfair to label using a known fast library over a known slow library as "premature optimization". I would much rather start a project or feature with the coding standard of, "use the fast ones", rather than have to go back through all the code, profile it, and replace only the ones hurting performance.

> start a project or feature with the coding standard of, "use the fast ones"

Ironically, that involves certain habit changes that completely obviate the library:

1) avoid map. Just create an array and write a for loop directly at the callsite, putting the code in a block rather than as a separate function

2) avoid indexOf. For single-character indexOf, it's much faster and much more efficient to match the character code (loop and check charCodeAt) than to use the function form

3) avoid lastIndexOf. Same as indexOf, except you loop in the opposite direction.

4) avoid forEach. Learn to love the for loop.

5) avoid reduce. See forEach

Anyone embracing fast.js is sacrificing some performance to begin with.

Umm okay, but that rather misses the point.

The point of this library is that it provides the same behavior (for 99.99% of cases) and the same abstraction (so same readability / maintainability) as the functions it replaces, but with significantly better performance (for wildly varying degrees of "significantly" depending on usage).

I don't think the idea is that you profile your code and then micro-optimize it using this library. If you're doing that (which you should, for varying definition of "should"), then yes you will want to consider sacrificing the abstraction / brevity for performance.

However, this library seems like a handy way to maintain the abstraction, while gaining performance essentially for free without sacrificing anything worth mentioning. Then you profile (if you were going to / had time to / cared enough to) and optimize from a better starting point. Don't see anything wrong with that.

My opinion is that JavaScript applications aren't losing that much performance by the use of lodash or fast.js but the gain in code brevity and readability more than makes up for any slight performance reduction. (Especially in a large web app where the tiny lodash library can save you many KB of boilerplate).

And with regard to performance, for most Node.js code / webapps if you have a loop with so many iterations that _.map is significantly slower than a for loop then you might be doing something wrong.

I have a feeling that certain things (e.g., reduce) will suddenly become much more performant with tail call optimization coming in ES6.

Would tail call optimization help in this case? AFAIK JS's iteration methods aren't recursive.

Tail call optimization isn't just for recursive tail call optimization (though that is the most common scenario!).

It simply refers to 'unrolling' that function call, so a new function doesn't need to be added to the stack.

JS's iteration methods aren't currently recursive, at least in V8[0]. But that's probably due to lack of TCO!

0. https://github.com/v8/v8/blob/master/src/array.js#L1378

So basically treat most of your JavaScript logic/functions as if you were writing C?

No, but using a non-spec compliant implementation across the board because "it's faster" is definitely premature optimisation. This is the sort of stuff that should be kept for performance critical bits, not used application wide.

Yeah but it could be a premature optimization if you blindly decided to use a library because the cost of having to download it (in the case of browser JS) and/or parse (in the case of server JS) an extra script file may outweigh its performance benefits.

In addition fast.js functions are not functionally identical to the native functions, just close enough for typical usage.

It may be premature optimization to use a faster library when the faster library has known places where it differs from standard behaviour, and almost certainly lots of bugs.

I don't know much about fast.js in particular but in this case there might be an advantage of using the fast functions simply because they have simpler semantics. There are many bugs and inconsistencies that come up from people expecting that native methods behave the same as simple for-loops when they actually don't.

http://kitcambridge.be/blog/say-hello-to-lo-dash/

I'd agree with you if we were comparing apples to apples.

This is not the case with Fast.js as it breaks away from the language specifications. I'd much rather build, profile, and then optimize the few areas that actually require better performance than potentially introduce bugs by replacing the built-in methods.

Reply on news.ycombinator.com