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

61–70 of 168 posts

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

#61

Post by coldtea »

Isofarro wrote: post #47
coldtea wrote: post #18

Earlier quoted context omitted.

Nothing "meaningless" about it. It's not like they do apples and oranges. They do slightly different varieties of apples -- ignore some BS edge cases that few ever use in the real world. If I rewrite project X into X v2 and throw away 2-3 seldom used features in the process, it doesn't mean that comparing v1 and v2 is meaningless. You compare for what people actually use it for -- the main use cases. Not for everythi…

Developers use forEach to apply a function to every element in an array. That is the main use case. This faster version fails on some arrays (any array that isn't contiguous). This is a bug, not a feature. The library user is now responsible for checking that the array is contiguous before using the faster function. Is it documented somewhere whether array returning/manipulating functions cause non-contiguity?

>This faster version fails on some arrays (any array that isn't contiguous). This is a bug, not a feature.

I'd argue it's actually a future.

For one, it's not forEach for one. It doesn't mask the native implementation. It exists in its own namespace.

Second, it's not like forEach doesn't have its own problems. Like not being backwards compatible to older browsers without shims.

Third, nobody (or very very small values of "somebody") use non contiguous arrays with forEach.

The speed is a great feature, especially if you don't sacrifice anything to achieve it.

>The library user is now responsible for checking that the array is contiguous before using the faster function.

The library user already knows if he is using contiguous arrays or not. After all, it can fuck him over in tons of other cases, even a simple for loop, or a length check, if he treats one like the other. So it's not like he doesn't already have to be vigilant about it.

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

#62

Post by cwmma »

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.

lodash is the fast one that pioneered this, underscore for the longest time fell back to slow native ones.

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

#63

Post by MokiD »

A while back I was programming for a naive but well-written JS interpreter for set top box apps, where map was generally being avoided because of performance.

I wrote quite a fast "map" (along with the others) that looked a bit like:

  exports.map = function fastMap (subject, fn, thisContext) {
    var i = subject.length,
        result = new Array(i);
    if (thisContext) {
      while (i--) {
        result[i] = fn.call(thisContext, subject[i], i, subject);
      }
    } else {
      while (i--) {
        result[i] = fn(subject[i], i, subject);
      }
    }
    return result;
  };
I'm not sure if I just used "result = []", but on modern browsers I think that'd be recommended. But yeah, if you're programming for a web browser then using another impl of map is probably going to be a waste of time.

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

#64

Post by ulisesrmzroche »

pestaa wrote: post #32
sp332 wrote: post #24

Earlier 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?

You programmed before? Implementations dont get simpler just because you wish them to.

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

#65

Post by coldtea »

coldnebo wrote: post #43
coldtea wrote: post #18

Earlier quoted context omitted.

Nothing "meaningless" about it. It's not like they do apples and oranges. They do slightly different varieties of apples -- ignore some BS edge cases that few ever use in the real world. If I rewrite project X into X v2 and throw away 2-3 seldom used features in the process, it doesn't mean that comparing v1 and v2 is meaningless. You compare for what people actually use it for -- the main use cases. Not for everythi…

From a computer science perspective it is formally 'meaningless' because the performance improvement was made by changing the requirements, not by a novel algorithm or data structure. This is always possible, but it ignores the original constraints of the problem and hence doesn't shed any additional meaning on how to solve the original problem. From a programmer perspective, that might not change the fact that it's…

>From a computer science perspective it is formally 'meaningless' because the performance improvement was made by changing the requirements, not by a novel algorithm or data structure.

I've studied computer science and I don't recall seing any such "formal" definition of meaninglessness.

Nothing in computer science tells you you have to have the exact same behavior in 2 APIs in order to measure some common subset of functionality. You can always restrict your measuremnts to that. Computer science is not that concerned with APIs anyway.

So you can use very formal computer science to compare the performance in big-O of X vs Y implementation of the common supported cases (namely, contiguous arrays).

>This is always possible, but it ignores the original constraints of the problem and hence doesn't shed any additional meaning on how to solve the original problem.

There's no "original" problem that one has to take wholesale. There are use cases, and some care about X, others about Y.

Scientific papers in CS compare implementations of things like filesystems, memory managers, garbage collectors etc ALL THE TIME, despite them not having the same API and one having some more or less features. They just measure what they want to measure (e.g performance of X characteristic) and ignore the others.

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

#66

Post by phpnode »

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),
        length = keys.length,
        key, i;
    for (i = 0; i
I'd rather write:

   every key of obj {
     // ...
   }
and have that expanded at compile time.

Additionally there are some cases where you must use inline for loops (such as when slicing arguments objects, see https://github.com/petkaantonov/bluebird/wiki/Optimization-k...) and a function call is not possible. These can also be addressed with sweet.js macros.

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

#67

Post by dabernathy89 »

> 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?

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

#68

Post by ulisesrmzroche »

VeejayRampay wrote: post #19

Javascript. The language where you can reimplement basic functions such as map, each, reduce (which by the way are still available for objects in 2014) and have them be faster than their native counterparts. It might be that I don't particularly like the language. but it's kind of frightening that we're building the world on that stuff.

Pfft. It's not as bad as you imagine.

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

#69

Post by xahrepap »

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.

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

#70

Post by throwaway_yy2Di »

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),…

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