Here's a jsperf of fast.js / lodash / native: http://jsperf.com/fast-vs-lodash
Fixed the rawgit link to use the rawgit cdn
Show HN: Fast.js – faster reimplementations of native JavaScript functions
101–110 of 168 posts
Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions
#102Earlier 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?
You programmed before? Implementations dont get simpler just because you wish them to.
Why the ad hominem?
I can make the implementation simpler if the underlying specification is simpler. If a language is full of edge cases, it was not designed carefully. If there exists a significantly faster implementation in a significantly slower language that covers 99% of the specification, I'd look for opportunities to simplify.
Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions
#103Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions
#104I think the forEach issue is a bad example, and something that could (and arguably should) be handled by the native implementation. The reason they get faster execution here is by breaking the spec.
A native implementation could have a single flag associated with the array recording whether it is sparse, and use the more efficient code path given here in the common space where it's non-sparse.
Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions
#105I think the forEach issue is a bad example, and something that could (and arguably should) be handled by the native implementation. The reason they get faster execution here is by breaking the spec. A native implementation could have a single flag associated with the array recording whether it is sparse, and use the more efficient code path given here in the common space where it's non-sparse.
sparse arrays are just one edge case that the native implementation must consider, see this comment - https://github.com/angular/angular.js/issues/6697#issuecomme...
Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions
#106Earlier 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.
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.
Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions
#107I think the forEach issue is a bad example, and something that could (and arguably should) be handled by the native implementation. The reason they get faster execution here is by breaking the spec. A native implementation could have a single flag associated with the array recording whether it is sparse, and use the more efficient code path given here in the common space where it's non-sparse.
The point I took away from that one example was: The native functions have to deal with lots of edge cases, which causes them to be slower. By implementing similar functions which, per their spec, do not handle those edge cases, we can gain a significant performance improvement.
Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions
#108Looks like John-David Dalton has some work cut out for him!
From what I remember, a primary reason Lodash was created as a fork of underscore was to address the "solution" that fastjs provides - underscore had problems with edge cases like sparse arrays, so lodash was created as a spec-compliant alternative. http://stackoverflow.com/a/13898916/1869609
Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions
#109Here's a jsperf of fast.js / lodash / native: http://jsperf.com/fast-vs-lodash
Thanks for that.
So looking at this in Firefox, the "fast" version underperforms the native one for forEach, bind, map, reduce, and concat. It outperforms native for indexOf/lastIndexOf.
In Chrome the "fast" version does better than the native one for indexOf, lastIndexOf, forEach, map, and reduce. It does worse on bind and concat.
It's interesting to compare the actual numbers across the browsers too. In Firefox, the numbers I see for forEach are:
"fast": 47,688
native: 123,187
"fast": 71,070
native: 20,112
"fast": 17,532
native: 62,268
"fast": 38,286
native: 19,521
Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions
#110Earlier quoted context omitted.
To be fair, it's not obvious if you're not a JS expert: coming from some other language, you could naively assume that function call gets inlined, with no overhead.
A few months ago, I tried some image processing with JS and the canvas object (big Arrays). They have a structure like image[pixel].color What I found was, always traversing the object structure was much slower than putting every pixel color as an argument in a function, that gets called every iteration. So I had the impression, reasonable simple function, like a greyscale filter, get inlined by engines like V8.
You probably would have been better off with typed arrays and fragment shaders, if you were going for performance.