Hacker News Reader

Comment by chmod775 | Hacker News Reader

I just ran this on a huge JS project that has a quite intensive "initialization" stage (modules being registered, importing each other, etc.), and prepack basically pre-computed 90% of that, saving some 3k LOC. I had to replace all references to "window" with a fake global object that only existed within the outer (function() {..})() though (and move some other early stuff with side effects to the end of the initialization), to get it to make any optimizations at all.

Very impressive overall.

View on HN

Wow. That is pretty impressive. Although as far as the changes you needed to make are considered, my understanding from a brief skim of the page was that `__assumeDataProperty` would be sufficient for supporting use of `window`.

It depends on what you use from window. If no functions on `window` are called during initialization you could just use `__assumeDataProperty` on all the properties of `window` you access.

If you call a function on `window` during initialization you would need to use `__residual` to emit the code into the residual program (assuming the call has no side effects on the heap that need to be seen by other initialization code). This is because otherwise Prepack cannot know how the abstract function would modify the heap (if it is an arbitrary function it could modify the global object for example), so it is not safe to execute.

How was the speedup? That's what I would use this for, not some small minification gains.

I'm gonna guess nothing. Static inline isn't going to help a language that needs to get compiled again in browsers. In all likelihood an engine like chrome will do all the optimizations they're doing and more.

It's like optimizing handwriting for readability than typing it out. You're running a transform on the code that changes the format completely, how optimized the original form is doesn't matter.

This sounds like very wrong reasoning. Yes, Chrome probably does some of this stuff, but that comes at a time cost that we could take at compile time, instead of at run time in the user's browser.

Someone on twitter seems to have done an experiment about startup time for a trivial app comparing the clojure compiler with and without Prepack:

https://twitter.com/roman01la/status/859849179149021184

Why guess when you could test it?

Do you happen to know if this is similar to what Google's Closure Compiler for javascriptw ould do?

It says on the bottom of the page that prepack optimizes for performance/less computation while closure optimizes for file size.

Closure Compiler does much of the same things; but I think prepack is looking to do considerably more compile-time evaluation; closure compiler only does some of this.

I think prepack will also generally generate larger, bulkier code than you might get out of closure compiler. When I give prepack code from closure compiler, it seems to make the code much larger but change nothing. Your mileage may vary.

Seems to not support some implementations of require() - did you have any problems?

Reply on news.ycombinator.com