4 ms·
This has promise but still needs more work. I added one line to their 9 line demo ( https://prepack.io/repl.html https://prepack.io/repl.html ) and it ballooned
by chime 9y ago
This has promise but still needs more work. I added one line to their 9 line demo ( https://prepack.io/repl.html https://prepack.io/repl.html ) and it ballooned to 1400+ lines of junk:
(function() {
function fib(x) {
y = Date.now(); // the useless line I added
return x <= 1 ? x : fib(x - 1) + fib(x - 2);
}
let x = Date.now();
if (x * 2 > 42) x = fib(10);
global.result = x;
})();
I understand Date might not be acceptable for inner loops but a lot of my code that deals with scheduling would benefit significantly if I could precompute some of the core values/arrays using a tool like prepack.
- shuzchen 9y agoIt's not a useless line, because prepack has no idea what Date.now() does (there are no guarantees in javascript that it hasn't been replaced with another function). It might mutate some global state somewhere, so the resulting code needs to call Date.now() as often as it would've if fib(10) was called. Basically the output is the unrolled version of the recursion, which cuts down on function invocation (comparatively expensive in dynamic languages). If you replaced the line with say: `var y = 4;` you'll notice that it has been optimized out.
- KallDrexx 9y agoBut should it still unroll the recursive calls and balloon the code out just because a mutatable function call was made, or should it leave it as an actual recursive function call.
- magicalist 9y ago> Basically the output is the unrolled version of the recursion, which cuts down on function invocation (comparatively expensive in dynamic languages). You're right about why it's included, but this is a bug, not a feature. If this is a hot function it'll be optimized. The recursive call is a known, non-dynamic invocation so the function location will be inlined leaving just the fairly low function call overhead itself. There's a reason nobody does arbitrary-length loop unrolls. I would definitely bet that this is a bug to be fixed :) Right now you can see this if you call fib(20) in that example...the compiler times out while trying to unroll that far. Clearly that behavior won't stick around.
- warent 9y ago"prepack has no idea what Date.now() does" isn't quite true, because there's a typeof check happening on the return to ensure it's a number, meaning that some assumptions are definitely being made.
- simlrh 9y agoAlso the lack of variable declaration in `y = Date.now()` made y an implicit global, so it couldn't be optimised out no matter what. Even doing `let y = Date.now()` cuts out 400 lines.
- developer2 9y agoDoesn't this make Prepack completely unusable? Surely it should try to apply its optimizations to each block of code, and for each block where the "optimized" version results in more lines of code - or perhaps better, more operations - the optimizations are thrown out, keeping that block of code untouched? It makes no sense to use an optimization tool that does the exact opposite in cases it cannot handle. In no world is 1400 lines better than 10.
- lexicality 9y ago"Prepack is still in an early development stage and not ready for production use just yet. Please try it out, give feedback, and help fix bugs."
- Francute 9y agoWell, if you have 1400 lines of 100 prime numbers each one, and a last line to retrieve one of them, if i ask for the 140.000 prime, that solution would be better (in terms of speed) than 10 lines making calcs for any prime number. If you know the possible range of accepted inputs, 1400 loc would be better than 10. One normally think much more loc is worst than a one line solution, but that's, like most answers, always depends. And that's a simple case. There are lot of similar cases one dont realize.
- Matheus28 9y agoEven better, it doesn't seem to ever give up on unrolling loops, this creates 60k lines: (function() { for(var i = 0; i < 10000; ++i){ Date.now(); } })();