No mention of relative memory usage though. I've been bitten by this kind of thing too many times in node in the past to not wonder about it here. Especially for such core functions.
Show HN: Fast.js – faster reimplementations of native JavaScript functions
31–40 of 168 posts
Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions
#32> In fact, native functions often have to cover complicated edge cases from the ECMAScript specification, which put them at a performance disadvantage. What. Is. This. I don’t even.
So if you simplify the implementation, it gets faster but more fragile. Why is that confusing?
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?
Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions
#33Earlier quoted context omitted.
So if you simplify the implementation, it gets faster but more fragile. Why is that confusing?
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.
Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions
#34I'm a bit concerned about this... On one hand, I'm a big proponent of "know your tools". I'll gladly use a fast sort function that falls apart when sorting arrays near UINT32_MAX size if I'm aware of that caveat ahead of time and I use it only in domains where the size of the array is logically limited to something much less than that, for example. But on the other hand, I write operating system code in C. I need to…
At least a list of the corners that are cut here would be nice.
Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions
#35[deleted]
this library does not overwrite any native functions or manipulate any prototypes, you have to call the fast.js versions explictly - it's opt in.
Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions
#36Earlier quoted context omitted.
An alternative interpretation might be - JavaScript, the high level language language that's so awesome that it can out perform native code* * as long as you make it do less work
Why isn't the native version doing less work? Isn't that what you expect from a language design, that the native version will be as close to optimal as possible in the first place?
The native versions have to/should 100% support the language spec and historical behavior. In this instance, it means they can't optimize much that iterates over a sparse array.
Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions
#37I'm a bit concerned about this... On one hand, I'm a big proponent of "know your tools". I'll gladly use a fast sort function that falls apart when sorting arrays near UINT32_MAX size if I'm aware of that caveat ahead of time and I use it only in domains where the size of the array is logically limited to something much less than that, for example. But on the other hand, I write operating system code in C. I need to…
At least a list of the corners that are cut here would be nice.
And a solid suite of unit tests.
The current set looks very light.
Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions
#38Earlier quoted context omitted.
Why isn't the native version doing less work? Isn't that what you expect from a language design, that the native version will be as close to optimal as possible in the first place?
Did you read the article? These functions are not 100% equivalent.
Fair enough. Why doesn't the title of the post say so then? "Faster incomplete versions of Javascript native functions" would have been a better summary.
Or even discuss the fact that if this library is good enough for people to use then maybe the edge cases that the native versions are covering might not be so useful after all?
Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions
#39I wonder how these compare to the ones in lodash.
... and to lazy.js : http://danieltao.com/lazy.js/
Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions
#40I did this with CPython and psyco. It turns out that writing map() in python was faster than the builtin C version. Because the JIT was allowed to do some tricks, like inlining the function.