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

71–80 of 168 posts

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

#71

Post by phpnode »

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 functions by doing less work overall.

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

#74

Post by thathonkey »

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.

Yeah but it could be a premature optimization if you blindly decided to use a library because the cost of having to download it (in the case of browser JS) and/or parse (in the case of server JS) an extra script file may outweigh its performance benefits.

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

#75

Post by netghost »

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.

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

#76

Post by phpnode »

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.

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

#77

Post by throwaway_yy2Di »

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.

I actually didn't get any speedup with that one -- looks like V8 can optimize that already. But you're right, that's an important one on some browsers.

You can squeeze out another factor of 2 with typed arrays:

    var input_typed = new Uint32Array(input)
    
    exports['numeric typed array'] = function() {
        var acc = 0;
        for (var j=0; j
And probably more still if you can figure out the asm.js incantation that makes everything statically typed.

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

#78

Post by k__ »

throwaway_yy2Di wrote: post #70
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),…

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.

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

#79

Post by nawitus »

thathonkey wrote: post #74
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.

Yeah but it could be a premature optimization if you blindly decided to use a library because the cost of having to download it (in the case of browser JS) and/or parse (in the case of server JS) an extra script file may outweigh its performance benefits.

In addition fast.js functions are not functionally identical to the native functions, just close enough for typical usage.

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

#80

Post by sheetjs »

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.

> 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 code (loop and check charCodeAt) than to use the function form

3) avoid lastIndexOf. Same as indexOf, except you loop in the opposite direction.

4) avoid forEach. Learn to love the for loop.

5) avoid reduce. See forEach

Anyone embracing fast.js is sacrificing some performance to begin with.

Post reply on HN