121–130 of 168 posts
It's fairly well-known that Array#forEach is up to an order of magnitude slower than a for-loop, across browsers. The usual reason given is the overhead of invoking a closure from the VM. A JS implementation of forEach ought to be somewhere in the middle. 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.
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.
I wonder which projects does actually need that. Hey I'm not bashing here, I thing it's kind cool for learning purposes attempts to do such thing, but I truly wonder if there is an actual production need for such thing.
Earlier quoted context omitted.
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 st…
The reason it incurs an overhead is because the DOM is traversed every single time the property is read, to ensure nothing has changed. You can see why caching the length is a reasonable optimisation, as you're unlikely to be modifying the collection while looping.
Earlier quoted context omitted.
> 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…
I have a feeling that certain things (e.g., reduce) will suddenly become much more performant with tail call optimization coming in ES6.
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 all the micro-optimizations, halving the number of lines, and fixed it so the dom was updated once.
Anyway, the point i'm making is this: you should micro-optimize for readability and robustness, not performance, unless profiling shows it's worth it. I haven't known a case where pure (non-dom, non-xhr) js code needed micro-optimization for performance in half a decade.
As a person who works on a JS engine I can say that a lot of the speed up in this library is the failure to handle holes correctly - it's surprisingly expensive to do a hole check, although there's still room in most engines to optimise it, those checks are fairly time consuming :-/
As a person who works on a JS engine I can say that a lot of the speed up in this library is the failure to handle holes correctly - it's surprisingly expensive to do a hole check, although there's still room in most engines to optimise it, those checks are fairly time consuming :-/
This seems like a potential win for JS performance in real-world applications -- an optimization hint to indicate whether an array is "overwhelmingly full of holes" or something less sparse where more optimized versions of the functions can be used.
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…
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…
An ignorant question -- why do people prefer to render graphics to SVG/DOM, when that's such a noticeable performance bottleneck?