Dojo Build system - improvements possible ?

classic Classic list List threaded Threaded
5 messages Options
MM
Reply | Threaded
Open this post in threaded view
|

Dojo Build system - improvements possible ?

MM
I have been looking at the results of dojo build and I'm quite surprised:

Why incremental numbers are used, even if each AMD module could use separate numbers ?
Think of Order of concat and shrinksafe …

Am I doing something wrong ?

./build.sh --profile base --release

This produces HUGE 120KB file !

Any hints ?
Any ideas ?
(could be about 80kbs easily !!!!)

For example if you shrink safe standalone "fx.js"
You will get

  *   Input Size: 20533
  *   Output Size: 5994

But if you shrink it as part of "Base profile build"

./build.sh --profile base --release

you will have about 10KB for the same source.

The main difference is in variable names

v1: Base build (concat, and shrink safe): indexing starts very high even dojo is considere a "short 4 letters name"
define(["./kernel", "./config", "./lang", "../Evented", "./Color", "./connect", "./sniff", "../dom", "../dom-style"], function (dojo, _119, lang, _11a, _11b, _11c, has, dom, _11d) {

v2: Shrink safe and concat:
define(["./kernel","./config","./lang","../Evented","./Color","./connect","./sniff","../dom","../dom-style"],function(_1,_2,_3,_4,_5,_6,_7,_8,_9){



I will look deeper now
I just expect some feedback please






________________________________________________________
Dojotoolkit: http://dojotoolkit.org
Reference Guide: http://dojotoolkit.org/reference-guide
API Documentation: http://dojotoolkit.org/api
Tutorials: http://dojotoolkit.org/documentation

[hidden email]
http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
Reply | Threaded
Open this post in threaded view
|

Re: Dojo Build system - improvements possible ?

neonstalwart
set the optimization to use closure compiler.  believe me it makes a  
huge difference and that's only using the simple optimizations mode of  
the closure compiler.  using the advanced optimizations would break  
dojo but could potentially result in even smaller builds if we could  
make it work.

ultimately, the plan is to add a parser to the build system (scheduled  
for 1.8) and produce an ast to help with the minification process.  
once we have the parser then we can really start to get creative with  
what optimizations work best for dojo's code.

thanks,

ben...


On Dec 16, 2011, at 7:12 PM, Marko Martin wrote:

> I have been looking at the results of dojo build and I'm quite  
> surprised:
>
> Why incremental numbers are used, even if each AMD module could use  
> separate numbers ?
> Think of Order of concat and shrinksafe …
>
> Am I doing something wrong ?
>
> ./build.sh --profile base --release
>
> This produces HUGE 120KB file !
>
> Any hints ?
> Any ideas ?
> (could be about 80kbs easily !!!!)
>
> For example if you shrink safe standalone "fx.js"
> You will get
>
>  *   Input Size: 20533
>  *   Output Size: 5994
>
> But if you shrink it as part of "Base profile build"
>
> ./build.sh --profile base --release
>
> you will have about 10KB for the same source.
>
> The main difference is in variable names
>
> v1: Base build (concat, and shrink safe): indexing starts very high  
> even dojo is considere a "short 4 letters name"
> define(["./kernel", "./config", "./lang", "../Evented", "./Color",  
> "./connect", "./sniff", "../dom", "../dom-style"], function (dojo,  
> _119, lang, _11a, _11b, _11c, has, dom, _11d) {
>
> v2: Shrink safe and concat:
> define(["./kernel","./config","./lang","../Evented","./Color","./
> connect","./sniff","../dom","../dom-
> style"],function(_1,_2,_3,_4,_5,_6,_7,_8,_9){
>
>
>
> I will look deeper now
> I just expect some feedback please
>
>
>
>
>
>
> ________________________________________________________
> Dojotoolkit: http://dojotoolkit.org
> Reference Guide: http://dojotoolkit.org/reference-guide
> API Documentation: http://dojotoolkit.org/api
> Tutorials: http://dojotoolkit.org/documentation
>
> [hidden email]
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest

________________________________________________________
Dojotoolkit: http://dojotoolkit.org
Reference Guide: http://dojotoolkit.org/reference-guide
API Documentation: http://dojotoolkit.org/api
Tutorials: http://dojotoolkit.org/documentation

[hidden email]
http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
MM
Reply | Threaded
Open this post in threaded view
|

Re: Dojo Build system - improvements possible ?

MM
Thanx ben


On 12/17/11 3:42 AM, "ben hockey" <[hidden email]> wrote:

>set the optimization to use closure compiler.  believe me it makes a
>huge difference and that's only using the simple optimizations mode of
>the closure compiler.  using the advanced optimizations would break
>dojo but could potentially result in even smaller builds if we could
>make it work.
>
>ultimately, the plan is to add a parser to the build system (scheduled
>for 1.8) and produce an ast to help with the minification process.
>once we have the parser then we can really start to get creative with
>what optimizations work best for dojo's code.
>
>thanks,
>
>ben...
>
>
>On Dec 16, 2011, at 7:12 PM, Marko Martin wrote:
>
>> I have been looking at the results of dojo build and I'm quite
>> surprised:
>>
>> Why incremental numbers are used, even if each AMD module could use
>> separate numbers ?
>> Think of Order of concat and shrinksafe Š
>>
>> Am I doing something wrong ?
>>
>> ./build.sh --profile base --release
>>
>> This produces HUGE 120KB file !
>>
>> Any hints ?
>> Any ideas ?
>> (could be about 80kbs easily !!!!)
>>
>> For example if you shrink safe standalone "fx.js"
>> You will get
>>
>>  *   Input Size: 20533
>>  *   Output Size: 5994
>>
>> But if you shrink it as part of "Base profile build"
>>
>> ./build.sh --profile base --release
>>
>> you will have about 10KB for the same source.
>>
>> The main difference is in variable names
>>
>> v1: Base build (concat, and shrink safe): indexing starts very high
>> even dojo is considere a "short 4 letters name"
>> define(["./kernel", "./config", "./lang", "../Evented", "./Color",
>> "./connect", "./sniff", "../dom", "../dom-style"], function (dojo,
>> _119, lang, _11a, _11b, _11c, has, dom, _11d) {
>>
>> v2: Shrink safe and concat:
>> define(["./kernel","./config","./lang","../Evented","./Color","./
>> connect","./sniff","../dom","../dom-
>> style"],function(_1,_2,_3,_4,_5,_6,_7,_8,_9){
>>
>>
>>
>> I will look deeper now
>> I just expect some feedback please
>>
>>
>>
>>
>>
>>
>> ________________________________________________________
>> Dojotoolkit: http://dojotoolkit.org
>> Reference Guide: http://dojotoolkit.org/reference-guide
>> API Documentation: http://dojotoolkit.org/api
>> Tutorials: http://dojotoolkit.org/documentation
>>
>> [hidden email]
>> http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
>
>________________________________________________________
>Dojotoolkit: http://dojotoolkit.org
>Reference Guide: http://dojotoolkit.org/reference-guide
>API Documentation: http://dojotoolkit.org/api
>Tutorials: http://dojotoolkit.org/documentation
>
>[hidden email]
>http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest

________________________________________________________
Dojotoolkit: http://dojotoolkit.org
Reference Guide: http://dojotoolkit.org/reference-guide
API Documentation: http://dojotoolkit.org/api
Tutorials: http://dojotoolkit.org/documentation

[hidden email]
http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
Reply | Threaded
Open this post in threaded view
|

Re: Dojo Build system - improvements possible ?

Jamey Graham
In reply to this post by neonstalwart
fwiw...i remember reading a discussion on this in the weekly meetings and rawld pointed out that gzipped versions of 1.7 were similarly sized to 1.6.  Perhaps i misinterpreted rawld and/or this question, but i took away that compression is a different beast than optimization (e.g. has() branching removing code), and compression should be left to the compression tools (and that compression tools don't seem to benefit much from this type of optimization...although this is simply what i recall reading vs. something i know to be true).



From: ben hockey <[hidden email]>
To: [hidden email]
Sent: Friday, December 16, 2011 9:42 PM
Subject: Re: [Dojo-interest] Dojo Build system - improvements possible ?

set the optimization to use closure compiler.  believe me it makes a 
huge difference and that's only using the simple optimizations mode of 
the closure compiler.  using the advanced optimizations would break 
dojo but could potentially result in even smaller builds if we could 
make it work.

ultimately, the plan is to add a parser to the build system (scheduled 
for 1.8) and produce an ast to help with the minification process. 
once we have the parser then we can really start to get creative with 
what optimizations work best for dojo's code.

thanks,

ben...


On Dec 16, 2011, at 7:12 PM, Marko Martin wrote:

> I have been looking at the results of dojo build and I'm quite 
> surprised:
>
> Why incremental numbers are used, even if each AMD module could use 
> separate numbers ?
> Think of Order of concat and shrinksafe …
>
> Am I doing something wrong ?
>
> ./build.sh --profile base --release
>
> This produces HUGE 120KB file !
>
> Any hints ?
> Any ideas ?
> (could be about 80kbs easily !!!!)
>
> For example if you shrink safe standalone "fx.js"
> You will get
>
>  *  Input Size: 20533
>  *  Output Size: 5994
>
> But if you shrink it as part of "Base profile build"
>
> ./build.sh --profile base --release
>
> you will have about 10KB for the same source.
>
> The main difference is in variable names
>
> v1: Base build (concat, and shrink safe): indexing starts very high 
> even dojo is considere a "short 4 letters name"
> define(["./kernel", "./config", "./lang", "../Evented", "./Color", 
> "./connect", "./sniff", "../dom", "../dom-style"], function (dojo, 
> _119, lang, _11a, _11b, _11c, has, dom, _11d) {
>
> v2: Shrink safe and concat:
> define(["./kernel","./config","./lang","../Evented","./Color","./
> connect","./sniff","../dom","../dom-
> style"],function(_1,_2,_3,_4,_5,_6,_7,_8,_9){
>
>
>
> I will look deeper now
> I just expect some feedback please
>
>
>
>
>
>
> ________________________________________________________
> Dojotoolkit: http://dojotoolkit.org
> Reference Guide: http://dojotoolkit.org/reference-guide
> API Documentation: http://dojotoolkit.org/api
> Tutorials: http://dojotoolkit.org/documentation
>
> [hidden email]
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest

________________________________________________________
Dojotoolkit: http://dojotoolkit.org
Reference Guide: http://dojotoolkit.org/reference-guide
API Documentation: http://dojotoolkit.org/api
Tutorials: http://dojotoolkit.org/documentation

[hidden email]
http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest



________________________________________________________
Dojotoolkit: http://dojotoolkit.org
Reference Guide: http://dojotoolkit.org/reference-guide
API Documentation: http://dojotoolkit.org/api
Tutorials: http://dojotoolkit.org/documentation

[hidden email]
http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
Reply | Threaded
Open this post in threaded view
|

Re: Dojo Build system - improvements possible ?

neonstalwart
to properly benefit from the removal of dead code via has() branching you need to use closure compiler.  if you use shrinksafe then you are getting a whole lot of these blocks that you won't get with closure

if (0) {
  // who cares what code is here? it should never make it to my build
}

this is extra weight that you don't need and effectively negates all the hard work put into using has().  regardless of the differences in compression between shrinksafe and closure, this dead code removal is very significant and is why i suggest to use closure.

ben...

On 12/19/2011 2:43 PM, Jamey Graham wrote:
fwiw...i remember reading a discussion on this in the weekly meetings and rawld pointed out that gzipped versions of 1.7 were similarly sized to 1.6.  Perhaps i misinterpreted rawld and/or this question, but i took away that compression is a different beast than optimization (e.g. has() branching removing code), and compression should be left to the compression tools (and that compression tools don't seem to benefit much from this type of optimization...although this is simply what i recall reading vs. something i know to be true).



From: ben hockey [hidden email]
To: [hidden email]
Sent: Friday, December 16, 2011 9:42 PM
Subject: Re: [Dojo-interest] Dojo Build system - improvements possible ?

set the optimization to use closure compiler.  believe me it makes a 
huge difference and that's only using the simple optimizations mode of 
the closure compiler.  using the advanced optimizations would break 
dojo but could potentially result in even smaller builds if we could 
make it work.

ultimately, the plan is to add a parser to the build system (scheduled 
for 1.8) and produce an ast to help with the minification process. 
once we have the parser then we can really start to get creative with 
what optimizations work best for dojo's code.

thanks,

ben...


On Dec 16, 2011, at 7:12 PM, Marko Martin wrote:

> I have been looking at the results of dojo build and I'm quite 
> surprised:
>
> Why incremental numbers are used, even if each AMD module could use 
> separate numbers ?
> Think of Order of concat and shrinksafe …
>
> Am I doing something wrong ?
>
> ./build.sh --profile base --release
>
> This produces HUGE 120KB file !
>
> Any hints ?
> Any ideas ?
> (could be about 80kbs easily !!!!)
>
> For example if you shrink safe standalone "fx.js"
> You will get
>
>  *  Input Size: 20533
>  *  Output Size: 5994
>
> But if you shrink it as part of "Base profile build"
>
> ./build.sh --profile base --release
>
> you will have about 10KB for the same source.
>
> The main difference is in variable names
>
> v1: Base build (concat, and shrink safe): indexing starts very high 
> even dojo is considere a "short 4 letters name"
> define(["./kernel", "./config", "./lang", "../Evented", "./Color", 
> "./connect", "./sniff", "../dom", "../dom-style"], function (dojo, 
> _119, lang, _11a, _11b, _11c, has, dom, _11d) {
>
> v2: Shrink safe and concat:
> define(["./kernel","./config","./lang","../Evented","./Color","./
> connect","./sniff","../dom","../dom-
> style"],function(_1,_2,_3,_4,_5,_6,_7,_8,_9){
>
>
>
> I will look deeper now
> I just expect some feedback please
>
>
>
>
>
>
> ________________________________________________________
> Dojotoolkit: http://dojotoolkit.org
> Reference Guide: http://dojotoolkit.org/reference-guide
> API Documentation: http://dojotoolkit.org/api
> Tutorials: http://dojotoolkit.org/documentation
>
> [hidden email]
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest

________________________________________________________
Dojotoolkit: http://dojotoolkit.org
Reference Guide: http://dojotoolkit.org/reference-guide
API Documentation: http://dojotoolkit.org/api
Tutorials: http://dojotoolkit.org/documentation

[hidden email]
http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest




________________________________________________________
Dojotoolkit: http://dojotoolkit.org
Reference Guide: http://dojotoolkit.org/reference-guide
API Documentation: http://dojotoolkit.org/api
Tutorials: http://dojotoolkit.org/documentation

[hidden email]
http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest

________________________________________________________
Dojotoolkit: http://dojotoolkit.org
Reference Guide: http://dojotoolkit.org/reference-guide
API Documentation: http://dojotoolkit.org/api
Tutorials: http://dojotoolkit.org/documentation

[hidden email]
http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest