Replacement for Closure-pass planned?

[Floh]

With all the improvements that have been incorporated into the emscripten build process to make builds faster and smaller, I think the Closure pass sticks out now like a sore thumb :)

The main problems are IMHO:

- It's slow, my most minimal sokol-sample which has a 51 KByte JS runtime (without closure) needs about 11 seconds for a full rebuild with closure enabled, and 4.7 seconds without closure but optimizations, and 2.5 seconds without closure and optimizations. For a single build target that's not much, but for a project with many targets (for instance my sample project has about 50 exe targets, which "blows up" to about 4 minutes without closure vs 9 minutes with closure).

- It depends on Java, which is becoming more and more an annoyance (see Oracles recent steps to take Java hostage, and it's yet another thing that must be installed).

On the other hand, Closure really reduces the Javascript runtime file dramatically, so it's a crucial step in the build process.

Are there any plans yet to eventually get rid of Closure and replace this with something less "annoying"?

[Alon Zakai]

I don't think there is any JS minifier that gives as good results as closure compiler (advanced, which is what we use). I'm not sure why closure takes as much time as it does, but it does do a lot of heavy work that no other minifier even tries to AFAIK (in particular, the potentially-unsafe minifying of JS object properties). So this is really a question for the larger JS ecosystem.

Regarding Java, yes, it would be nice to remove that dependency, and there is a JS port of Closure. It is not faster though, but it might start up faster, so on small projects it might be quicker. See this PR:

https://github.com/emscripten-core/emscripten/pull/5464

Help on landing that PR would be very welcome!

- Alon

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/f3531ea7-4b98-4d43-8286-158aa46fd4be%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jukka Jylänki]

I have been eyeing at replacing the Java Closure version with the
JavaScript version of Closure. It is unfortunate that removing Java
dependency and speeding up minification performance are at odds
against each other, though for our use case, we are considering
Closure minification to be a "shipping release" type of activity
rather than something one would do in a "development release"
iteration builds.

Apart from that, I recommend trying out the emprofile.py toolchain
profiler tool to see if some particular hotspots would pop up there.
Perhaps there's something that would dominate across the multiple
builds that might give ideas to look for further optimizations.

> To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpQq5VGYtN069-rB93chzUSOJV3VDL4H6iKBCbiKwyidiA%40mail.gmail.com.

[Floh]

Understood, thanks for the hints on profiling :)

>> To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.

>> To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/f3531ea7-4b98-4d43-8286-158aa46fd4be%40googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.