Their first example for (let _i = 0; _i This is recalculating length on each iteration
Show HN: Faster.js – a micro-optimizing JavaScript compiler
31–37 of 37 posts
Re: Show HN: Faster.js – a micro-optimizing JavaScript compiler
#32This is cool, but array methods are so rarely the bottleneck; Even in the highly-specialized demo, the difference is near-negligible. It's a fun project and might have application in specialized situations (and maybe for Node, where time spent in synchronous iteration blocks all other requests?). But I feel like this does more harm than good in most cases (larger bundle, extra build step, less readable output code ca…
Re: Show HN: Faster.js – a micro-optimizing JavaScript compiler
#33Earlier quoted context omitted.
Closure compiler in ADVANCED_OPTIMIZATIONS mode does this too. function add5(x) { return x + 5; } console.log(add5(3)); compiles down to console.log(8);
Prepack is doing much more than GCC can because it effectively evaluates the whole code and then serialises its heap. This is both its biggest strength and weakness. Unlike GCC, it can unroll any kind of metaprogramming, but it needs to have a model of the environment (e.g. it won’t execute code relying on DOM) and it can produce larger code (in terms of absolute size).
Admittedly it doesn't take JS as input, but I was somewhat confused when I read your comment nonetheless.
Re: Show HN: Faster.js – a micro-optimizing JavaScript compiler
#34Re: Show HN: Faster.js – a micro-optimizing JavaScript compiler
#35Re: Show HN: Faster.js – a micro-optimizing JavaScript compiler
#36It could be faster according to this test: https://jsperf.com/extended-array-loops-performance