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

Stephen Chung Stephen.Chung at intexact.com
Wed Mar 16 00:40:25 EDT 2011

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20110316/5ecbe06d/attachment-0001.htm 

More information about the dojo-contributors mailing list