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

111–120 of 168 posts

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

#111

Post by warfangle »

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…

I have a feeling that certain things (e.g., reduce) will suddenly become much more performant with tail call optimization coming in ES6.

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

#113

Post by nathanb »

phpnode wrote: post #44
nathanb wrote: post #27

I'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…

This is actually unlikely to be a problem. The edge cases ignored here are actually the same as those ignored by underscore.js, which is obviously a very popular library.

I agree that it's unlikely to be a problem...until your site gets popular and a .01% corner case becomes a weekly occurrence or until someone sees that you're using fast and exploits an attack vector.

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

#114

Post by Excavator »

phpnode wrote: post #66
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…

regarding your edit, you're exactly right, of course a for loop will be faster. Sometimes you really do need a function call though, in which case fast forEach and map implementations become more useful. The next step for fast.js are some sweet.js macros which will make writing for loops a bit nicer, because it's pretty painful to write this every time you want to iterate over an object: var keys = Object.keys(obj),…

Note that 'in'

    for (key in object)
is for getting keys, in Firefox, meanwhile 'of'

     for (value of iterator)
is for getting values out of an Iterator.

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

#115

Post by phpnode »

nathanb wrote: post #113
phpnode wrote: post #44

Earlier quoted context omitted.

This is actually unlikely to be a problem. The edge cases ignored here are actually the same as those ignored by underscore.js, which is obviously a very popular library.

I agree that it's unlikely to be a problem...until your site gets popular and a .01% corner case becomes a weekly occurrence or until someone sees that you're using fast and exploits an attack vector.

it's not that kind of edge case. It simply means that some very uncommon constructs are not supported. If you never use those constructs, which basically nobody does, then it will never fail. (and in fact the failure mode is pretty soft and unlikely to crash your application). If your code worked with this once, it will always work.

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

#116

Post by olliej »

As a person who works on a JS engine I can say that a lot of the speed up in this library is the failure to handle holes correctly - it's surprisingly expensive to do a hole check, although there's still room in most engines to optimise it, those checks are fairly time consuming :-/

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

#117

Post by olliej »

Excavator wrote: post #114
phpnode wrote: post #66

Earlier quoted context omitted.

regarding your edit, you're exactly right, of course a for loop will be faster. Sometimes you really do need a function call though, in which case fast forEach and map implementations become more useful. The next step for fast.js are some sweet.js macros which will make writing for loops a bit nicer, because it's pretty painful to write this every time you want to iterate over an object: var keys = Object.keys(obj),…

Note that 'in' for (key in object) is for getting keys, in Firefox, meanwhile 'of' for (value of iterator) is for getting values out of an Iterator.

Most of the array methods are explicitly defined in terms of indexing rather that iterators, so for(of) is incorrect. On the other hand indexing is still faster than iteration in the major implementations.

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

#118

Post by phpnode »

Excavator wrote: post #114
phpnode wrote: post #66

Earlier quoted context omitted.

regarding your edit, you're exactly right, of course a for loop will be faster. Sometimes you really do need a function call though, in which case fast forEach and map implementations become more useful. The next step for fast.js are some sweet.js macros which will make writing for loops a bit nicer, because it's pretty painful to write this every time you want to iterate over an object: var keys = Object.keys(obj),…

Note that 'in' for (key in object) is for getting keys, in Firefox, meanwhile 'of' for (value of iterator) is for getting values out of an Iterator.

the only issue is i'd like to differentiate between iterating arrays and objects at the syntax level. Coffeescript uses `in` for arrays and `of` for objects, but I agree that becomes confusing. Open to other suggestions!

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

#120

Post by bzbarsky »

phpnode wrote: post #76
jrajav wrote: post #73

Here's a jsperf of fast.js / lodash / native: http://jsperf.com/fast-vs-lodash

thanks for this! it looks like there's some room for improvement in the .map / .forEach implementations but the rest seems to stack up pretty well.

The native bind in Firefox is much faster than the fast.js one (not surprising, since it has explicit JIT support).
Post reply on HN