Hacker News Reader

Comment by sheetjs | Hacker News Reader

> 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.

View on HN

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?

Reply on news.ycombinator.com