NTillmann

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's not yet ready for production, so there are some bugs and cases where we should reject a program but don't do that yet.

Having said that, it's quite safe, but won't be undetectable. Code using eval could detect injected identifiers, we don't currently aim at preserving function names, and the method bodies you get with toString() are altered. That should be roughly it.

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

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.

Prepack is quite complementary to traditional compilers. It's strength is that it comes with full knowledge of the JavaScript built-ins, and it uses that to pre-evaluate the code at compile time. In an extreme case, an entire program can get reduced to the final result.

Hi, I am Nikolai Tillmann, a developer on the Prepack project. I am happy to answer any questions!