[dojo-contributors] Code size reductions: Dojo 1.6 with Closure vs. Shrinksafe

Stephen Chung Stephen.Chung at intexact.com
Sat Mar 5 00:11:52 EST 2011

Hi all,
Just to follow up on the potential code size reductions with Closure Advanced mode compilation.  I’ve done some comparative tests on my own application, with the following results.  Application is divided into three layers: dojo.js, dijit.js (containing dojox.mobile) and user.js.  Second column of numbers are gzipped sizes.
Uncompressed sizes of normal Build, on average shrinking library code by 70% gzipped (low compression perhaps due to comments):
    dojo.js.uncompressed.js:           335KB        100KB (30%)
    dijit.js.uncompressed.js:            395KB        109KB (28%)
    i18n bundle:                               2KB            1KB (50%)
    user.js.uncompressed.js:           306KB        55KB (18%)
    Total:                                          1.01MB      263KB (26%)
Shrinksafe build, shrinking library code by 60-75% non-gzipped, 90% gzipped:
    dojo.js:             77KB  (23%)           27KB (8%)
    dijit.js:              145KB  (37%)         41KB (10%)
    i18n bundle:     2KB                        1KB (50%)
    user.js:             152KB  (50%)         33KB (11%)
    Total:                373KB (37%)          100KB (10%)
Closure Advanced Mode build (actual output is one single file, but I’ve separated it into the original sections).  Saving 1/4 over Shrinksafe, but only a few % over raw uncompressed text:
    dojo.js section:             51KB  (15%)    21KB  (6%)
    dijit.js section:              88KB  (22%)    31KB  (8%)
    i18n bundle section:     2KB                 1KB  (50%)
    user.js section:             70KB  (23%)    21KB  (7%)
    Total section:                210KB (21%)   71KB  (7%)
    Note: since the output is one single file, compression is slightly better than the sum of separate files due to common substrings.
    Reference compile with no renaming: 108KB gzipped.  This is not scientific, but a hack to get an intermediate result.
It is confirmed that renaming global variables and properties to shorter versions yield little benefits (2-3%) when compared to the original raw text files.  The % reduction appears to be higher when comparing gzipped outputs (around 1/4 savings over Shrinksafe), but in absolute terms it is only 30KB.
This 1/4 saving appears to be entirely due to shortening of names, because a reference build I compiled with Closure without renaming turns out to be slightly larger than Shrinksafe.
This also brings out the fact that there is currently very little dead-code removal, due to the way dojo and dijit are written.  With full dead code removal, potentially one can reduce the dojo.js section by another 1/3 or so – something like 7KB.
However, the small numbers involved probably indicate that it is not worth fussing over because Dojo itself is already very compact when gzipped.  The incentive to use Closure’s renaming feature has to be driven by need for obfuscation and the need to squeeze out every last drop of performance on a low-speed device.
- Stephen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20110305/1b07ae4c/attachment-0001.htm 

More information about the dojo-contributors mailing list