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

Post by couchand » Wed, Jun 25, 2014, 1:10 PM UTC

babby wrote: post #160

JoshTriplett wrote: post #91

Earlier quoted context omitted.

> Additionally, since you pretty much never need the return value of splice, you can just not return anything instead of allocating a wasted array every time That kind of optimization seems easily done with a builtin as well: have an option to return the array, and only do so if the JavaScript engine indicates that the calling code actually uses the return value.

That seems like something well suited to compile-to-js languages like Coffeescript. It could substitute cases as you mentioned with fast.js equivalent functions.

Post by couchand » Wed, Jun 25, 2014, 1:32 PM UTC

alttab wrote: post #53

tekacs wrote: post #45

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…

Post by ulisesrmzroche » Wed, Jun 25, 2014, 2:03 PM UTC

AshleysBrain wrote: post #146

Joeri wrote: post #126

Today i was refactoring some js code that rendered a graph to svg. It was taking several seconds in some cases, and the developer had done a bunch of micro-optimizations, inlining functions, building caches to avoid nested loops, and so on. I ran a profile. The code ran for 2.5 seconds, 4 ms of which in the micro-optimized js code, the rest updating the dom, five times all over again. Needless to say that i threw out…

Having written a major HTML5 game engine, I've ended up micro-optimizing JS code after small functions really did show up high in profiling measurements. One example: calculating a bounding box from a quad involved code along the lines of Math.min(a, b, c, d) followed by Math.max(a, b, c, d). Replacing that with a tree of ifs to determine both the minimum and maximum at once was faster and moved the bottleneck elsewh…

Post by Excavator » Wed, Jun 25, 2014, 7:37 PM UTC

phpnode wrote: post #164

couchand wrote: post #162

Earlier quoted context omitted.

I've been spending some time thinking about CoffeeScript's choice for `in` and `of` and I think I have the answer: they should be more regular. One (probably `of`) should be used for the keys/indexes and the other (probably `in`) should be used for contents. These are legal CoffeeScript examples: for key, value of object if key of object for value in array if value in array for index, value of array if index of array…

The issue with coffeescript is that it uses the opposite syntax to JS - `in` for arrays instead of objects. ES6 introduces the `of` keyword for real iterators so i don't really want to use that for either of them. It's tricky. There are other options but they're verbose every element as key, value from arr { console.log(key, value); } every property as key, value from obj { console.log(key, value); }

    every [key, value] from arr {
      console.log(key, value);
    }

    every {key, value} from obj {
      console.log(key, value);
    }

    every [key] from arr {
      console.log(key);
    }

    every {_, value} from obj {
      console.log(value);
    }