5 ms·

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 basic

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.

michaelmior 10y ago
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`.
- cblappert 10y ago
  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.
MaxLeiter 10y ago
Seems to not support some implementations of require() - did you have any problems?
maaaats 10y ago
How was the speedup? That's what I would use this for, not some small minification gains.
- slackingoff2017 10y ago
  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.
  - maaaats 10y ago
    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.
    - cblappert 10y ago
      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 https://twitter.com/roman01la/status/859849179149021184
  - placeybordeaux 10y ago
    Why guess when you could test it?
adamsea 10y ago
Do you happen to know if this is similar to what Google's Closure Compiler for javascriptw ould do?
- wlib 10y ago
  It says on the bottom of the page that prepack optimizes for performance/less computation while closure optimizes for file size.
- microcolonel 10y ago
  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.

michaelmior 10y ago

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`.

cblappert 10y ago
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.

MaxLeiter 10y ago

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

maaaats 10y ago

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

slackingoff2017 10y ago
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.
- maaaats 10y ago
  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.
  - cblappert 10y ago
    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 https://twitter.com/roman01la/status/859849179149021184
- placeybordeaux 10y ago
  Why guess when you could test it?

adamsea 10y ago

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

wlib 10y ago
It says on the bottom of the page that prepack optimizes for performance/less computation while closure optimizes for file size.
microcolonel 10y ago
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.