[dojo-contributors] Thoughts on dead-code removal and the DojoToolkit

Stephen Chung Stephen.Chung at intexact.com
Wed Mar 16 05:40:14 EDT 2011

Hi Eugene,

Unused code removal does not have to be removed a "module" basis, but 
usually on a function/class level.  Multiple large functions typically do 
not need to be separated into separate modules -- dead code removal works 
fine within the module.  An optimizer can usually determine which blocks of 
code within a module is never visited.

It is dojo.declare'd classes that pose a problem, because they cannot be 
determined by any optimizer whether they are used or not (since they may be 
loaded declaratively).  This is currently an existing limitation because any 
class used declaratively must be specifically pulled in with dojo.require 
statements. The solution may be to either:

1) Make each class its own module (as you mentioned), so when pulling in one 
class it does not pull in anything else.  Of course, classes that work 
together as a coherent whole can reside in the same module since they'll all 
be required.

2) Provide a list of *classes* to the optimizer (not modules, which may 
contain multiple classes) so that it can decide what classes are not needed 
and so can remove them.

- Stephen

-----Original Message----- 
From: Eugene Lazutkin
Sent: Wednesday, 16 March, 2011 1:10 PM
To: dojo dev.
Subject: Re: [dojo-contributors] Thoughts on dead-code removal and the 

Hash: SHA1

Sounds like we need to go to "one dojo.declare'd object per file", and
even probably "one processing unit (e.g., a significant function) per
file" splitting. Is it a valid assumption?


Eugene Lazutkin

On 03/15/2011 11:40 PM, Stephen Chung wrote:
> I’ve recently done more experiments on dead-code removal, since I have
> succeeded in virtualizing the “dojo” namespace.  My application also now
> pulls in dojox.charting (which pulls in dojox.lang, dojox.color and
> dojox.gfx) and I am now fine-tuning my techniques in dealing with Closure.
> My observation is that dead-code removal is not significant for Dojo.
> There are a few reasons:
> - Dojo is written in a very compact way, with many cross-callings among
> functions to save space.
> - Dijit is very modular, and code within a module are usually all needed.
> - Classes declared via dojo.declare cannot be removed (as they are
> probably needed declaratively).  So, although some modules define many
> optional classes (e.g. the plot styles in dojox.charting), they all
> stayed and cannot be removed even though I used only one class out of 
> many.
> - Code removed are usually small functions.  Large blocks of code are
> seldom unused (although typically only small sections of these large
> functions are touched).  Currently it looks like 10-20% of code can
> typically be removed, but no more.
> - Feature detection code must be replaced by constants in order to
> remove unneeded code branches when building for a specific platform.
> For example: if (“localStorage” in window) ... is not
> dead-code-removable, but: if (has(“localStorage”)) can be removed if
> this has() call is re-mapped to a constant false for a special build.
> Therefore, in order to facilitate dead code removal (by any means, not
> just Closure), the following has to be considered:
> 1) Heavy modularization – the smaller the modules the better; this can
> eliminate code at the merge stage of the build
> 2) Favor a lot of smaller functions vs. large functions that do a lot of
> things – optimizers can in-line then and remove unused functions – but
> this conflicts with the drive for higher performance when the js is not
> processed by an optimizer.
> 3) Find a way to specify (for the build process) which dojo.declare’d
> classes will be needed by the parser and which will not.
> 4) Replace detection code with something like has.js (which I see
> discussed actively) that enables an optimizer to remove entire branches
> of code based on hard-coded feature sets specified during a build for a
> particular platform.
> - Stephen
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at mail.dojotoolkit.org
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

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.894 / Virus Database: 271.1.1/3509 - Release Date: 03/16/11 

More information about the dojo-contributors mailing list