Amazing, the "performance tests" here operate on a list of only ten items long: https://github.com/codemix/fast.js/blob/master/bench/for-eac...
I'm sure that is a statistically valid way to measure performance.
Show HN: Fast.js – faster reimplementations of native JavaScript functions
41–50 of 168 posts
Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions
#42Amazing, the "performance tests" here operate on a list of only ten items long: https://github.com/codemix/fast.js/blob/master/bench/for-eac... I'm sure that is a statistically valid way to measure performance.
you're right in that it's important to consider inputs of different sizes. I did this for the indexOf() functions, I'll do the same here, thanks!
Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions
#43Earlier quoted context omitted.
They're non compliant - it's a meaningless comparison as the two implementations do different things.
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 useful. It has 'meaning' to the programmer in that it helps us solve a particular problem. Typically, app programmers are not as concerned with how the problem was solved.
I like the library, but to avoid this kind of criticism, don't call it a reimplementation. Call it what it is, an alternative library of functions.
Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions
#44I'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.
Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions
#45I'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…
I think by all means use this for a shopping cart - it's namespaced by require (say under 'fast' as in the README) - you are, for all intents and purposes, calling just some library which just happens to reimplement JS builtins as its mode of operation.
It may even be _easier_ to determine the behaviour of these functions than builtins, since determining how fast works just means reading its source whereas to determine builtins' behaviour you must read the ECMAScript specification and then hope[1] that the browser actually matches it perfectly!
[1]: or read the JS engine source, but that's a whole lot more work. :P
Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions
#46Premature 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 50% faster than using the functional suspects. But that, in the eyes of some people, unnecessarily adds complexity to the code and may not be worth changing
Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions
#47Earlier quoted context omitted.
They're non compliant - it's a meaningless comparison as the two implementations do different things.
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?
Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions
#48Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions
#49Earlier 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?
if you've ever written a for loop like this, you'd see the exact same issue.
for (i = 0, total = arr.length; i Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions
#50I 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 function calls):
// new benchmark in bench/for-each.js
exports['explicit iteration'] = function() {
acc = 0;
for (var j=0; j