Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Fast.js – faster reimplementations of native JavaScript functions

github.com

Post reply on HN
Print view View original

81–90 of 168 posts

Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions

#81

Post by nawitus »

netghost wrote: post #75
throwaway_yy2Di wrote: post #50

I think in most cases where you'd worry about JS array performance you should use actual numeric arrays [0] rather than the kitchen sink Array(). Also, I think those function abstractions have a pretty significant overhead? [0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Type... (edit): Yeah, the abstraction overhead is ridiculous. Here's the forEach() benchmark again, compared to an explicit for loop (no…

One other micro optimization for you. Assuming the length of the array does not change in the operation, this is usually faster: for (var j=0, len=input.length; j This prevents rechecking the array length on every iteration.

The length is not recalculated on every pass. However it's slightly faster.

http://stackoverflow.com/questions/17989270/for-loop-perform...

Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions

#83

Post by pdpi »

xahrepap wrote: post #69
sheetjs wrote: post #46

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…

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.

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.

Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions

#84

Post by Kiro »

So the forEach magic that is so much faster is... a normal for loop:

  exports.forEach = function fastForEach (subject, fn, thisContext) {
    var length = subject.length,
        i;
    for (i = 0; i
I knew that forEach was slower than a normal for loop but I was expecting something more.

Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions

#85

Post by danabramov »

Reminds me of this comment by Petka Antonov on native V8 Promises being way slower than Bluebird[1]:

>I'd expect native browser methods to be an order of magnitude faster.

Built-ins need to adhere to ridiculous semantic complexity which only gets worse as more features get added into the language. The spec is ruthless in that it doesn't leave any case as "undefined behavior" - what happens when you use splice on an array that has an indexed getter that calls Object.observe on the array while the splice is looping?

If you implemented your own splice, then you probably wouldn't even think of supporting holed arrays, observable arrays, arrays with funky setters/getters and so on. Your splice would not behave well in these cases but that's ok because you can just document that. Additionally, since you pretty much never need the return value of splice, you can just not return anything instead of allocating a wasted array every time (you could also make this controllable from a parameter if needed).

Already with the above, you could probably reach the perf of "native splice" without even considering the fact that user code is actually optimized and compiled into native code. And when you consider that, you are way past any "native" except when it comes to special snowflakes like charCodeAt, the math functions and such.

Thirdly, built-ins are not magic that avoid doing any work, they are normal code implemented by humans. This is biggest reason for the perf difference specifically in the promise case - bluebird is extremely carefully optimized and tuned to V8 optimizing compiler expectations whereas the V8 promise implementation[2] is looking like it's directly translated from the spec pseudo-code, as in there is no optimization effort at all.

[1]: https://github.com/angular/angular.js/issues/6697#issuecomme...

[2]: https://github.com/v8/v8/blob/master/src/promise.js

Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions

#86

Post by [deleted] »

Kiro wrote: post #84

So the forEach magic that is so much faster is... a normal for loop: exports.forEach = function fastForEach (subject, fn, thisContext) { var length = subject.length, i; for (i = 0; i I knew that forEach was slower than a normal for loop but I was expecting something more.

[deleted]

Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions

#87

Post by sheetjs »

danabramov wrote: post #85

Reminds me of this comment by Petka Antonov on native V8 Promises being way slower than Bluebird[1]: >I'd expect native browser methods to be an order of magnitude faster. Built-ins need to adhere to ridiculous semantic complexity which only gets worse as more features get added into the language. The spec is ruthless in that it doesn't leave any case as "undefined behavior" - what happens when you use splice on an a…

His "optimization killers" article is also really insightful: https://github.com/petkaantonov/bluebird/wiki/Optimization-k...

Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions

#88

Post by franze »

micro-benchmarks are the root of all evil

http://www.youtube.com/watch?v=65-RbBwZQdU Vyacheslav Egorov - LXJS 2013 talk

i don't know if he actually said these word, but it was the overall theme of this (very entertaining and very enlightening) talk.

Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions

#89

Post by driverdan »

sheetjs wrote: post #46

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…

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

Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions

#90

Post by sheetjs »

driverdan wrote: post #89
sheetjs wrote: post #46

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…

> 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 im…

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

Post reply on HN