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

Stephen Chung Stephen.Chung at intexact.com
Sun Mar 6 20:39:22 EST 2011

Hi Bill,

The Closure Compiler never renames two properties to the same mangled name.  For local variables, I believe both Shrinksafe and Closure will start with simple names anyway (like _1, _2 etc.)

I do believe some of the differences came from one feature of Closure to reuse variables within a scope.  If it detects a variable not used after a certain statement, it will “reuse” it for a variable defined later on without opening up a new one.  Function parameters are also reused similarly.  In essence, a function may have 5 local variables which compresses to five short names in Shrinksafe, but only one in Closure.

By observing Closure’s debug output, I regularly see variables/arguments that used to substitute for 2-3 local variables.

- Stephen

From: Bill Keese 
Sent: Saturday, 05 March, 2011 8:34 PM
To: dojo dev. 
Cc: Stephen Chung 
Subject: Re: [dojo-contributors] Code size reductions: Dojo 1.6 with Closure vs. Shrinksafe

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.
  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


No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 9.0.872 / Virus Database: 271.1.1/3482 - Release Date: 03/05/11 03:34:00
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20110307/851cd2c1/attachment-0001.htm 

More information about the dojo-contributors mailing list