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

Bill Keese bill at dojotoolkit.org
Wed Mar 16 07:24:47 EDT 2011


Can you explain what you mean by this?

dojo.declare'd classes that pose a problem, because ... they may be
> loaded declaratively


Also, would it make things better to do:

var Foo = dojo.declare(...);

rather than this:

dojo.declare("Foo", ...)


On Wed, Mar 16, 2011 at 6:40 PM, Stephen Chung
<Stephen.Chung at intexact.com>wrote:

> 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
> DojoToolkit
>
> -----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
>
>
>
>
>
>
>
> 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
> 03:34:00
>
> _______________________________________________
> 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/20110316/4584496f/attachment.htm 


More information about the dojo-contributors mailing list