On the demo page in Chrome, Faster.js is actually slower.
[deleted]
Show HN: Faster.js – a micro-optimizing JavaScript compiler
21–30 of 37 posts
Re: Show HN: Faster.js – a micro-optimizing JavaScript compiler
#22Earlier quoted context omitted.
Prepack is rather nice. It allows you to execute part of your code at compile time, like a macro.
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).
Re: Show HN: Faster.js – a micro-optimizing JavaScript compiler
#23This is a good example of premature optimization.
I think this is an example of _optimization_. An optimization that is easily applied as a transform for Babel, but that's just it. Whether it is premature or not, it would depend on if you apply it carelessly without knowing whether you need it, or if you apply it when you know you need. Right?
The optimization is transforming all code that matches the pattern independent from whether the code is hot or not.
The transformation comes with cognitive cost for the developer as it can turn correct code into incorrect code (sparse arrays).
By enabling this one trades complexity for potential performance gains.
This is how I understand premature.
Re: Show HN: Faster.js – a micro-optimizing JavaScript compiler
#24Optimizing JavaScript is hard.
v8 for instance, has the interpreter (ignition), and optimizing compiler (turbofan), that have a lot of undocumented behavior that people just to try to probe via microbenchmarks.
- https://en.wikipedia.org/wiki/Inline_caching
- https://static.googleusercontent.com/media/research.google.c...
If you want to understand what is going on the only way is to read v8's source code or running a profiler.
For example, did you know that touching the prototype of a RegExp object makes it slow? You had no way of knowing that.
Re: Show HN: Faster.js – a micro-optimizing JavaScript compiler
#25Earlier 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).
oh, cool. thanks for the info.
Re: Show HN: Faster.js – a micro-optimizing JavaScript compiler
#26Re: Show HN: Faster.js – a micro-optimizing JavaScript compiler
#27This is a good example of premature optimization.
I think this is an example of _optimization_. An optimization that is easily applied as a transform for Babel, but that's just it. Whether it is premature or not, it would depend on if you apply it carelessly without knowing whether you need it, or if you apply it when you know you need. Right?
Is it an optimization when it makes things slower?
Re: Show HN: Faster.js – a micro-optimizing JavaScript compiler
#28I'd like to be able to specify restrictions on type usage in Javascript. For instance, in some cases I know that my array will always be 6 items larges - no smaller, no larger, never sparse. But I can't specify this, yet it allows for certain optimizations (e.g. loop unrolling).
Lately I was memory profiling an application in Javascript using Chrome. The fact that it used ES6 classes really helped, as some anonymous classes where hard to find memory leaks with, but the typed classes was a simple text query.
I can imagine ES6 classes with decorators may enable specialized optimizations too.
Re: Show HN: Faster.js – a micro-optimizing JavaScript compiler
#29This 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…
To the extent this tool will make it appear that there is less usage of functional JS patterns browser vendors deciding how to optimize their engines, I'm not a fan. Compiling away a useful feature or pattern just because it's not yet optimized creates a risk of a self-fulfilling prophecy. Obviously this is not a zero-sum game and optimizing for one pattern doesn't necessarily mean that something else must suffer, but prioritization of what to optimize is sometimes based on instrumentation measuring deployed usage and not just artificial benchmarks.
The performance gap between a `for` loop and and a `.forEach` (also map) is much narrower than it used to be, and that is very encouraging.
Re: Show HN: Faster.js – a micro-optimizing JavaScript compiler
#30Their first example
for (let _i = 0; _i This is recalculating length on each iteration