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

Bill Keese bill at dojotoolkit.org
Wed Mar 16 22:13:14 EDT 2011


FYI, I finished up splitting apart widgets per file in
http://bugs.dojotoolkit.org/ticket/12420, put in the
http://docs.dojocampus.org/releasenotes/1.7 too.

On Wed, Mar 16, 2011 at 9:48 PM, Peter Higgins <dante at dojotoolkit.org>wrote:

> 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.
>
> ~phiggins
>
> On 3/16/11 1:10 AM, Eugene Lazutkin wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > 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
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.10 (GNU/Linux)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> >
> > iEYEARECAAYFAk2ARk0ACgkQY214tZwSfCvFSwCaA0VDHwxQKYeJTy0daYX9BMdi
> > dtQAnRhTF5+VPeXcmC3hP2MyOnset7nw
> > =58we
> > -----END PGP SIGNATURE-----
> > _______________________________________________
> > dojo-contributors mailing list
> > dojo-contributors at mail.dojotoolkit.org
> > http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
>
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at mail.dojotoolkit.org
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20110317/81ba590a/attachment-0001.htm 


More information about the dojo-contributors mailing list