51–60 of 168 posts
The speed-up for "concat" is surprising to me. I wonder if it holds for "splice" and if that is true across browsers.
Earlier quoted context omitted.
... and to lazy.js : http://danieltao.com/lazy.js/
Thanks, I hadn't come across this one before. Looks like they are expecting some API changes in the future though so I'll just bookmark this one for now.
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…
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 determi…
Now, if fast.js made sure we had the correct requirements, no distractions, clear milestones, and a dedicated team with no turn over, I'd import it in a second.
blah | 0; // fast!
Math.floor(blah); // slow(er)! (except on FF nightly)
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.
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!
Earlier quoted context omitted.
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 determi…
I'm not sold that this will provide any user-measurable increase in performance. If you are sold by some personal app benchmark, there is a good chance you are writing too much client side JS. And what is to say of other dependencies like jQuery, Bootstrap, Knockout, Angular, etc that do NOT use fast.js under the hood? It seems that the only real "win" I get is a fast "map" command, which, IFAIK, has NEVER been the p…
I just take objection to the perspective given by the parent post on the _safety_ situation surrounding this library.
[1]: ... not recently, anyway.
Here's another one for you, one of my favorites that used to be drastic: http://jsperf.com/pipetrunc blah | 0; // fast! Math.floor(blah); // slow(er)! (except on FF nightly) Caveat: Only works with numbers greater than -2147483649 and less than 2147483648.
> -0.5
-0.5
> (-0.5)|0
0
> Math.floor(-0.5)
-1Javascript. 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.
This would likely get even faster if you manually specialized a map/forEach/etc for each caller, but then you might as well just write the loop out by hand: http://rfrn.org/~shu/2013/03/20/two-reasons-functional-style...
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…
This is very often overlooked but extremely useful for implementations of fast algorithms in JavaScript that should scale to a lot of input data.
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…
I used this in a Firefox OS app, inside an implementation of Dijkstra's algorithm and an accompanying binary heap, and while I haven't run any rigorous benchmarks, I can say the runtime felt way better on my test phone when I rewrote the algorithm to use the typed arrays. This is very often overlooked but extremely useful for implementations of fast algorithms in JavaScript that should scale to a lot of input data.