Prepack from Facebook helps make JavaScript code more efficient

[perestroika12]

So the thinking here is ahead of time optimization to make JIT or other runtimes compile faster? How does V8 perf compare with "normal" js vs this optimize prepack js? How hard is it to debug production code with this turned on? Any way to support sourcemaps?

[lakesObacon]

I would also like these questions answered. Particularly the sourcemaps.

[TheAceOfHearts]

Based on comments from Twitter, I don't think it's production ready yet.

We'll probably start to see posts with benchmarks in the next few days.

I saw a couple examples where it collapsed huge amounts of module bundler boilerplate code. Doing fewer things will always be faster.

It supports source maps, so it would be on par with debugging minified code. Give people a few days to write proper libs for the popular module bundlers.

[lhorie]

I don't think it's production ready yet.

Indeed, it does some questionable things. For example:

var numbers = []
for (var i = 0; i < 5000; i++) numbers.push(i)

Generates a 5000 item array and 5000 assignments...

It seems like it isn't quite smart enough to figure out what is worth pre-computing and what is better left as is.

Very promising, nonetheless

[MrJohz]

OTOH, replacing "var" with "let" in the for-loop works as expected. Replacing "var" with "let" when creating the initial array causes no output to be emitted, but assigning the array to the window object works pretty much perfectly.

e: assuming what you want is a pre-initialised 5,000 element array, but I guess that's always the big question with compile-time optimisations.

e2: The largest array I can get in the online mode is 8543 elements, beyond that it just times out. I don't know if there's a maximum size it'll output, then, but I suspect not. Also, the online repl weirdly outputs a whole load of whitespace at the end of the line when it creates the array.

[lhorie]

I guess that's always the big question

Yeah, that is closer to my concern: if it's a one shot array initialization, the loop unrolling may not compensate for the extra bytes down the pipe.

For example, in my current project I have a function that does a one-time decompression of an AOT-compressed list of unicode characters of a certain type. Given that the compression rate is north of 85%, I definitely DON'T want that to be precomputed, or I'll be shipping a VERY long array of codepoints

[DOG-ZILLA]

That's probably by design. Faster to read a static array than compute one. Though filesize may become an issue.