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

91–100 of 168 posts

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

#91

Post by JoshTriplett »

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…

> 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

That kind of optimization seems easily done with a builtin as well: have an option to return the array, and only do so if the JavaScript engine indicates that the calling code actually uses the return value.

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

#92

Post by NathanKP »

sheetjs wrote: post #80
xahrepap wrote: post #69

Earlier quoted context omitted.

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…

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.

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

#93

Post by illumen »

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…

Specialisation in JavaScript JITs make these faster, since they don't even compile in that supporting code.

Whereas the builtin ones implemented in C++ do keep all the code in there.

This is why even full implementations written in JavaScript can be faster than C++.

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

#94

Post by al2o3cr »

sheetjs wrote: post #57
simonsarris wrote: post #54

Here's another one for you, one of my favorites that used to be drastic: http://jsperf.com/pipetrunc blah | 0; // fast! Math.floor(blah); // slow(er)! (except on FF nightly) Caveat: Only works with numbers greater than -2147483649 and less than 2147483648.

Another caveat: for negative numbers, the bit-or rounds to zero while the floor rounds to negative infinity: > -0.5 -0.5 > (-0.5)|0 0 > Math.floor(-0.5) -1

A fine example why this sort of "who needs the specs, FULL SPEED AHEAD" hyper-optimization can get people into trouble.

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

#96

Post by dabernathy89 »

phpnode wrote: post #71
dabernathy89 wrote: post #67

> there is essentially no performance difference between native functions and their JavaScript equivalents > native functions often have to cover complicated edge cases from the ECMAScript specification, which put them at a performance disadvantage. Aren't these opposing statements?

no, but I could probably have worded it better. What I mean to say is that if you do this in JS: function add (a, b) { return a + b; } and this in C: int add(int a,int b) { return a + b; } you're going to get essentially the same performance. The latter sentence you quoted refers to the specific builtin functions that fast.js re-implements. So we first get close to native performance in JS, then we beat the builtin f…

gotcha, thanks for the clarification

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

#97

Post by pestaa »

sp332 wrote: post #33
pestaa wrote: post #32

Earlier quoted context omitted.

If you simplify the specification, a proper implementation gets faster with no downside. Why can't we build software on simpler platforms with better implementations?

Doing something complex on a simple platform requires complex code. https://en.wikipedia.org/wiki/Turing_tarpit Having a more complex platform can make things a lot easier for the programmer.

Simplicity never meant easy. Doing something complex on a simple platform may as well use simple constructs and benefit from no edge cases.

For example, Haskell provides only a handful of constructs but allows the developer to build sophisticated systems.

Though I agree complex platforms are not necessarily complicated.

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

#98

Post by recursive »

spyder wrote: post #39
netcraft wrote: post #3

I wonder how these compare to the ones in lodash.

... and to lazy.js : http://danieltao.com/lazy.js/

Wow, very cool. It seems to be linq for javascript, moreso than libraries that actually advertise themselves as linq for javascript.

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

#100

Post by CJefferson »

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.

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.
Post reply on HN