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

Bill Keese bill at dojotoolkit.org
Sat Mar 5 07:34:44 EST 2011


That's actually an impressive improvement over shrinksafe.

I don't think the savings is from shorter names; it's probably from having
the same names repeatedly used for every class.   Since every class has
methods named a, b, c,d e, the same string repeats often and we get good
compression.

2011/3/5 Stephen Chung <Stephen.Chung at intexact.com>

>   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.
>
>  Observations:
>
>  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
>
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at mail.dojotoolkit.org
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20110305/92dca9f8/attachment.htm 


More information about the dojo-contributors mailing list