Awesome work! Are there plans to incorporate Flow definitions as an alternative to the __assumeDataProperty helpers?

Edit: Looks like this is targeting compiler output, so Flow types would typically be gone by that stage. Integration with Flow could come via a babel plugin that emits `__assumeDataProperty()` when it encounters a convertible Flow type.

(can't edit my post any more)

I made a plugin to do this here - https://github.com/codemix/flow-runtime/tree/master/packages...

What will happen if you have bug in your function? Take the fibonacci function for example, what if you have a bug and created an infinite loop? Will Prepack terminate?

I was thinking something similar: how does Prepack determine that a function can't be optimized or hits an infinite loop? Seems like the good ol Halting Problem[0].

[0]: https://en.wikipedia.org/wiki/Halting_problem

The Halting Problem is a bit like Information Theory.

Information Theory, and the Pigeon Hole Principle in specific, says there is no algorithm that can compress all data. That doesn't mean that compression is a fruitless endeavor and we should never have written a compression library.

It means that you have to figure out if your input falls into a subset of data where the outcome of the effort is both tractable and useful. You compress text and structured data, you don't compress noisy data or already compressed data, because it's usually worse than doing nothing.

Similar thing with code analysis. If there is back branching or asynchronous code, you are probably going to hit the Halting Problem, so don't even try. But if the code is linear, then precomputing the output is tractable and useful.

You could also simply apply a budget. If an attempt to unroll a block of code exceeds a certain number of clock cycles or branch operations, you should give up and look at the next most likely scenario. The analysis you're doing might reliably halt in an hour, but who wants to wait that long? Especially when it's one of many such evaluations you'll have to do per build or per day? Just give up and keep moving.

GCC doesn't crash if you tell it to unroll loops with an infinite while loop in your code, does it?

But you can get into infinite loops with templates!

This is fucking impressive!

Just evaluated this:

   (function() {
   var a = 'a';
   var b = [a, 'b', 'c']
    .filter((i, index) => i.charAt( 1 - index)  !== 'b')
    .map(i => i + '!')
    .join(',')
   console.log(b)
   })()

BTW how you avoid going to infinite loops?

Another question: Does this use Flow types to optimize things like object member properties?

That is not surprising, your filter/map/join only use constants, it probably does an eval().

Thoughts on supporting source maps or something like it? It's very common to use source maps on production code when debugging live site issues and it's nice to have that translation capacity.

Webpack handles sourcemaps, and one of us, gajus, has already integrated it. Prepack should be just another stage in the build pipeline.

Having said that, there appears to be a sourceMaps flag in the Prepack source: https://github.com/facebook/prepack/blob/57cc59c07d164e4827c...

I will be attempting to use this as a simple black box, relying on Webpack for features that are only tangentially related to this new optimization stage in my build stack.

Can it be plugged into webpack for production builds? (I know it's not production ready yet)

Yes, as of about 25 mins ago - https://github.com/gajus/prepack-webpack-plugin

Hah, nice. Love it.

Are you seeing a noticeable improvement in peak performance using prepack or does it mostly help improve initial performance and warm up?

Currently, it's really about the initialization phase of the code.

How do you validate your program transformations? In school I wrote a haskell to clojure translator that also does AST transforms (some of which unpack syntactic sugar). However, my only way to validate the transforms was that the input program passe the "same" unit tests as the output program. Do you have any insight into this?

Hi! Judging from the comments only this looks to be a great tool. Good job!

I'm a developer currently learning more backend and JS. I hope this question doesn't come out as arrogant. I heard once that "a good compiler should be able to compile itself". Does prepack prepack itself to run faster or can it just for the fun of it? :-)

Not quite. This PR is almost ready to do it.

https://github.com/facebook/prepack/pull/397

Currently it is blocked on Map/Set support in the output which is an outstanding issue. We could also try it with a Map/Set polyfill.

We're very close to being able to though!

In fact, this isn't just Prepack itself but it is Prepacking the JS part of the entire Node.js runtime as well!

Can you provide any indications of the size of performance improvements?

To really see the benefits, you need to use it an environment where the parsing overhead gets cached. In terms of pure execution time, we see improvements of up to 10x for the initialization phase.

Thanks for posting here Nikolai.

In terms of the development status, does the current codebase generally work with React?

I'm happy to throw this at my codebase and report bugs, but whether React itself (which is ~95% of my bundle size) is expected to work (unlike some other optimising products) would say a lot about what the expectation might be.

It's a brilliant tool, bravo! Why did you go down that road instead of heap snapshot? Portability?

Conceptually, Prepack would go together well with heap snapshots, as Prepack figures out what is the concrete heap, and what are residual computations. If we tweak Prepack to completely separate these two aspects in the generated code, then you'd heap snapshot after the concrete part has been build, and still run the fixup code at runtime.

It doesn't seem like this tool supports global level objects.

For instance, a common pattern being:

(function(w) { console.log(w.location); })(window)

This results in issues because it's unaware that window would contain other methods. Is it possible to exclude certain objects in this case?

Do you have any papers you recommend to learn more about symbolic execution? Can you describe a high level overview of the process while citing the relevant source files in Prepack? Cool stuff!

Do you have any performance benchmarks?

What kind of symbolic values does Prepack have, and what kinds of constraints on them does it understand?

I used Pex a lot, very cool to see your next project is _also_ PL Magic :)

Can you prove that any of the optimizations in your docs aren't already done by V8? I agree with the other commenters in this thread-- V8 likely does these already. You have an extraordinary claim, which requires extraordinary proof.

The whole point is to not let V8 do any job at all.

V8 == user impacted.

Compile time V8 == compiler impacted, users happy.

It's like interpreting what you can during compile time, with caching capabilities.

To speed up boot time and init time, not runtime per say.

This. By transforming and evaluating things that really could be constants beforehand, V8 has less to do when it goes to run the javascript.

V8, like all tiered JITs, doesn't do many optimizations unless the code to be optimized is hot. This is the right thing for V8 to do, because most code on the Web is cold and so it's better to just run the code rather than sitting there optimizing it. But it does mean that there are a lot of optimizations that would be profitable to perform in the aggregate that are nevertheless unprofitable to do at runtime, because the time spent to optimize outweighs the running time of the unoptimized code. AOT optimizers like Prepack can solve this dilemma, by doing expensive optimizations ahead of time so that doing them won't eat into the runtime of the program.

That's not all, there's the cost of (down)loading the dead code, and startup cost for loading the unoptimised cost. Even more critical when you consider environments where you can't JIT, like React Native on iOS for instance, which was one of the many motivations for Prepack AFAIK.

It's much better to do this earlier. If you're asking v8 to optimise, say, the whole of React on a mobile device before first paint, that's definitely going to be slower than having the same optimisations done before V8 needs to parse/optimise it!