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

Stephen Chung Stephen.Chung at intexact.com
Sun Mar 6 23:33:22 EST 2011

Hi Bill,

It is correct that foo, bang, bar and baz will be mangled to four different names.  For Closure, the mapping between each unique text name and mangling is a one-to-one mapping to avoid some very subtle bugs in twisted programs.  There is an experimental flag to make it “reuse” manglings, but not turned on by default.

Your example will be renamed to:

    dojo.declare(“One”, { a:1, b: 2});
    dojo.declare(“Two”, { c:1, d: 2});

However, if you then have: 

    var another = { foo:”hello”, baz:”world” };

it will still be renamed:

    var e = { a:”hello”, c:”world” };

The predictable one-to-one mapping is what makes it possible to marry Dojo with the compiler.

- Stephen

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

I assumed if we had two classes: 

dojo.declare("One", {
    foo: 1,
    bang: 2


dojo.declare("Two", {
    baz: 1,
    bar: 2

... that it would rename those attributes the same way in each class:

dojo.declare("One", {
    _1: 1,
    _2: 2


dojo.declare("Two", {
    _1: 1,
    _2: 2

Are you saying that's not the case, that it keeps the attribute names unique across the whole project?

On Mon, Mar 7, 2011 at 10:39 AM, Stephen Chung <Stephen.Chung at intexact.com> wrote:

  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


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

More information about the dojo-contributors mailing list