Rich-Harris
commented
7 years ago It depends on the codebase. GCC performs better on some — domvm apparently being one of them — but not others. I'll re-run the numbers in a bit and post them
Open leeoniya opened 7 years ago
Rich-Harris
commented
7 years ago It depends on the codebase. GCC performs better on some — domvm apparently being one of them — but not others. I'll re-run the numbers in a bit and post them
leeoniya
commented
7 years ago Uglify's at 16.4 KB. i wonder why GCC does so much better :/
EDIT: just to be clear, i'd prefer to move to a Rich Harris tooling monoculture 😆
Rich-Harris
commented
7 years ago Alright, I ran some numbers — minified, zipped, and times. (Don't pay too much attention to the times, I'm half way through figuring out a better way to benchmark this stuff — it doesn't seem to make sense to minify each file multiple times so that functions warm up when minifiers typically run cold.)
You can see that it really does depend on the codebase. For every domvm or Moment, there's a Backbone — 8.29kb zipped in Closure, 7.47kb in Uglify and 7.57 in Butternut — or a jQuery/Immutable/Ramda/React, etc. Need to chart these numbers but I would say that Closure is generally either the largest output or the second largest behind Babili. I think domvm is perhaps an unusual case (note that I'm testing the closure-compiler-js, not the Java version — will edit the README to make that clearer).
It looks like Closure is often injecting some polyfills ($jscomp) which are probably unnecessary. It's possible that I'm doing something wrong, but I tried fiddling with e.g. the languageOut option and all I get are cryptic errors.
Anyway, it's early days — there's no reason in principle that Butternut can't adopt the same optimisations that Uglify and Closure have perfected, but there are reasons that Uglify, Closure and Babili will never be as fast as Butternut 😉
leeoniya
commented
7 years ago the speed of closure-js is terrible. the way i got rid of $jscomp in the Java version was by setting ECMASCRIPT6_STRICT in and ECMASCRIPT5_STRICT out [1].
[1] https://github.com/leeoniya/domvm/blob/2.x-dev/build.js#L142
Rich-Harris
commented
7 years ago I think that must be a Java-only option, it doesn't seem to have any effect on the JS output. Perhaps we should try and benchmark the Java version as well in the interests of complete fairness.
leeoniya
commented
7 years ago https://raw.githubusercontent.com/mrdoob/three.js/dev/build/three.js
java -jar compiler.jar --language_in=ECMASCRIPT6_STRICT --language_out=ECMASCRIPT5_STRICT --js three.js --js_output_file three.min.js
java -jar compiler.jar --language_in=ECMASCRIPT5_STRICT --language_out=ECMASCRIPT5_STRICT --js three.js --js_output_file three.min.js
produces 491k 495k (with . runs in 4-5s on my rather modest Thinkpad T440S; none of this $jscomp, couldnt get rid of them with this codebase)1m 9.1s nonsense.
when the JS port of GCC was announced [1], my first impulse was to test it out [2] cause i'm one of those people who hates "compile everything to js just because we can now". 3-4x slowdown seems to have been a rather generous assessment. looks like the slowdown is O(n^2) with respect to code size.
[1] https://news.ycombinator.com/item?id=13116526 [2] https://news.ycombinator.com/item?id=13117165
Rich-Harris
commented
7 years ago Wow. I'd assumed that since closure-compiler-js was compiled from the Java source, it would yield the same results (compression-wise, not perf-wise). Needs a 'don't actually use this!' notice on the repo.
Have updated the README to make it clear I'm talking about the -js version.
jbmonroe
commented
7 years ago You guys are killing me. GCC is the GNU C++ compiler. I'm thinking "what? The c++ compiler compresses JavaScript?"
Rich-Harris
commented
7 years ago Ha, yep — GNU C++ Compiler !== Google Closure Compiler 😆
leeoniya
commented
7 years ago yeah sry, i started seeing that abbr used recently and it threw me off too, but Github doesnt have autocomplete and who has the time to write it all out (what are we, C++ devs :D)?
Unfortunately this claim is factually not true today, not by a long shot in fact:
https://github.com/leeoniya/domvm/blob/2.x-dev/dist/dev/domvm.dev.min.js
GCC yields 15.6 KB. butternut comes in at 16.7 KB.
The good news is that it passes ~97% of the written tests after compilation and compresses impressively fast. I haven't checked how the final build performs in benchmarks, but GCC does a good amount optimizations that result in faster perf vs Uglify.