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

Stephen Chung Stephen.Chung at intexact.com
Wed Mar 16 22:16:07 EDT 2011


Hi Bill,

Dojo allows creation of dijits declaratively (e.g. dojoType=”dijit.layout.ContentPane” in HTML).  The parser looks up the class via its *unmangled* name.  An optimizer, without knowledge of the HTML, cannot decide whether a class will be loaded by the parser via HTML declarations.

Currently, I modified the build script to convert dojo.declare(“foo.bar”...) to foo.bar = dojo.declare(“foo.bar”...) anyway.  Therefore, currently I mapped both mangled class variable and unmangled namespace variables to the same object.  Therefore, the mangled class can be used in further dojo.declare’s as base class, and the unmangled variables are needed for the parser to instantiate the class.

- Stephen

From: Bill Keese 
Sent: Wednesday, 16 March, 2011 7:24 PM
To: dojo dev. 
Cc: Stephen Chung 
Subject: Re: [dojo-contributors] Thoughts on dead-code removal and the DojoToolkit

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




--------------------------------------------------------------------------------

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


More information about the dojo-contributors mailing list