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

Bill Keese bill at dojotoolkit.org
Sun Mar 6 23:07:58 EST 2011


I assumed if we had two classes:

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

and

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
});

and

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 <bill at dojotoolkit.org>
> *Sent:* Saturday, 05 March, 2011 8:34 PM
> *To:* dojo dev. <dojo-contributors at mail.dojotoolkit.org>
> *Cc:* Stephen Chung <Stephen.Chung at intexact.com>
> *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.
>>
>>  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
>>
>>
>
> ------------------------------
>
> 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/8b125892/attachment-0001.htm 


More information about the dojo-contributors mailing list