Furthermore if you run GCC in a warmed up JVM (such as a service, or within a build tool like SBT), then the times go radically down. For example within SBT the first run of GCC takes 16.5s, but then it drops to 11-12s. Same file run through Uglify takes 7.1s to process. So the differences are not that big anymore, especially considering that the final JS is 100% larger with Uglify :)
Unfortunately GCC does not offer a daemon/service mode (except via their web API), so using GCC in an optimal way in a JS project is not that easy.
GCC has slow start-up (being Java), so it suffers from running it individually on a lot of small files. A more realistic scenario would be to compare the two when run on a bundled result.
For example running both on a 3.8MB JS file produced by the Scala.js compiler the results are:
GCC 931k 24s (220k GZ)
Uglify 1943k 9s (318k GZ)
Most of the size difference comes from the fact that Uglify doesn't do as good a job at name mangling as GCC does, on a global level.
Comment
Furthermore if you run GCC in a warmed up JVM (such as a service, or within a build tool like SBT), then the times go radically down. For example within SBT the first run of GCC takes 16.5s, but then it drops to 11-12s. Same file run through Uglify takes 7.1s to process. So the differences are not that big anymore, especially considering that the final JS is 100% larger with Uglify :)
Unfortunately GCC does not offer a daemon/service mode (except via their web API), so using GCC in an optimal way in a JS project is not that easy.
Parent comment
GCC has slow start-up (being Java), so it suffers from running it individually on a lot of small files. A more realistic scenario would be to compare the two when run on a bundled result. For example running both on a 3.8MB JS file produced by the Scala.js compiler the results are: GCC 931k 24s (220k GZ) Uglify 1943k 9s (318k GZ) Most of the size difference comes from the fact that Uglify doesn't do as good a job at name mangling as GCC does, on a global level.