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

Eugene Lazutkin eugene at lazutkin.com
Wed Mar 16 01:10:47 EDT 2011

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/


More information about the dojo-contributors mailing list