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

Peter Higgins dante at dojotoolkit.org
Wed Mar 16 08:48:34 EDT 2011

That was ultimately the decision in Dijit, though some still have 
multiple declares for private mixins/classes. There should always be a 
1:1 mapping of require vs whatyouget.


On 3/16/11 1:10 AM, Eugene Lazutkin wrote:
> 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?
> Cheers,
> Eugene Lazutkin
> http://lazutkin.com/
> 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/
> dtQAnRhTF5+VPeXcmC3hP2MyOnset7nw
> =58we
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at mail.dojotoolkit.org
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors

More information about the dojo-contributors mailing list