Build version optimizations

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

Build version optimizations

Gaetan de Menten
Hello again,

I've looked at what gets generated by a ./generate build of my
application and I think there is room for much improvement. Is any of
the following (sorted from easy to hard) planned?

Should do (IMO)
=============

- loader code optimization: the "part loader" code, seem to not be
optimized at all: it contains comments, indentation, etc... Besides,
it "leaks", the global variable "isMshtml" (ie a variable not in the
qooxdoo namespace): is it intended or an oversight?

- better resource key names to save space.
Currently, the way to represent combined images is very wasteful:
Couldn't this:
 "qx/decoration/Modern/shadow/shadow-small-r.png": [5, 136, "png",
"qx", "qx/decoration/Modern/shadow-small-lr-combined.png", 0, 0],
be transformed to something like this:
"qx/decoration/Modern/shadow/": {
    "shadow-small-r.png": [5, 136, "png", "qx", "small-lr-combined.png", 0, 0],

The code would probably be very slightly more complex, but it would be
worth it IMO.

- better translations key names to save space
As for resource names, it is currently very wasteful and almost ridiculous:
Couldn't this

"cldr_month_abbreviated_11": "Nov", "cldr_month_abbreviated_10": "Oct", ...

be changed to something like this:

"month": {
    "abbreviated": {
         10: "Oct",
         11: "Nov",
         ...

And in this case, even the code would probably be simpler than currently.

- newline stripping

I think this used to be possible with the 0.7 build system, but I
can't find a way to enable this in 0.8.

- not "optimizing" string literals that are used only once.

There are lot of those and this waste space and possibly a bit of load time.

Could do but probably hard
======================

- optimization of protected/public method and variable names, a

- optimization of class names.

- removal of unused code (methods).

Dreamland
=========

- automatic inlining of code if space is saved. Could possibly also
add a configurable speed/space tradeoff factor: "inline even if
resulting code is X larger".
This would save quite some space *and* make the code run faster.


--
Gaëtan de Menten
http://openhex.org

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Build version optimizations

Gaetan de Menten
Replying to myself, as I sent it by mistake while it wasn't
finished... Sorry guys...

On Mon, Oct 13, 2008 at 12:17 PM, Gaetan de Menten <[hidden email]> wrote:

> I've looked at what gets generated by a ./generate build of my
> application and I think there is room for much improvement. Is any of
> the following (sorted from easy to hard) planned?
>
> Should do (IMO)
> =============
>
> - loader code optimization: the "part loader" code, seem to not be
> optimized at all: it contains comments, indentation, etc... Besides,
> it "leaks", the global variable "isMshtml" (ie a variable not in the
> qooxdoo namespace): is it intended or an oversight?
>
> - better resource key names to save space.
> Currently, the way to represent combined images is very wasteful:
> Couldn't this:
>  "qx/decoration/Modern/shadow/shadow-small-r.png": [5, 136, "png",
> "qx", "qx/decoration/Modern/shadow-small-lr-combined.png", 0, 0],
> be transformed to something like this:
> "qx/decoration/Modern/shadow/": {
>    "shadow-small-r.png": [5, 136, "png", "qx", "small-lr-combined.png", 0, 0],
>
> The code would probably be very slightly more complex, but it would be
> worth it IMO.
>
> - better translations key names to save space
> As for resource names, it is currently very wasteful and almost ridiculous:
> Couldn't this
>
> "cldr_month_abbreviated_11": "Nov", "cldr_month_abbreviated_10": "Oct", ...
>
> be changed to something like this:
>
> "month": {
>    "abbreviated": {
>         10: "Oct",
>         11: "Nov",
>         ...
>
> And in this case, even the code would probably be simpler than currently.
>
> - newline stripping
>
> I think this used to be possible with the 0.7 build system, but I
> can't find a way to enable this in 0.8.
>
> - not "optimizing" string literals that are used only once.
>
> There are lot of those and this waste space and possibly a bit of load time.
>
> Could do but probably hard
> ======================
>
> - optimization of protected/public method and variable names.
>
> - optimization of class names.

The most effective way would be to do it cross-namespaces: for
example, renaming qx.ui.form.Spinner to "a1", qx.io.remote.Request to
"a2", etc...
Of course, names should be allocated on a shorter names go to names
with more occurences. This would save tons of space I think.

> - removal of unused code (methods).

I noticed that unused methods gets included in the build version. I
have a couple methods in my classes that are only used for debugging,
but even if I comment the calls to those methods, the definition of
the methods gets included. I'm not sure how much such a mechanism
would save but I bet there is a substential part of the code which is
never used (either directly or indirectly -- ie it is used only by
other code which is itself not used). A tiny example is all the
"abstract" methods which contain some error message.

> Dreamland
> =========
>
> - automatic inlining of code if space is saved. Could possibly also
> add a configurable speed/space tradeoff factor: "inline even if
> resulting code is X larger".
> This would save quite some space *and* make the code run faster.

I'd really love to see this kind of feature. Unfortunately, I guess
this is too hard to achieve by Qooxdoo developers alone. This makes me
think: couldn't the "minifier" part of the build process be released
as a standalone tool so that we can pool the effort of minizing code
with other projects? With the rise of developing applications on the
web, there should be more and more people interested in such
technologies.

Thanks for reading me
--
Gaëtan de Menten
http://openhex.org

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Build version optimizations

thron7
In reply to this post by Gaetan de Menten

> - loader code optimization: the "part loader" code, seem to not be
>  

Agreed, but again there is a "larger" plan in place, to put most of the
loader code into a regular framework class, so there isn't much
incentive to optimize the current solution.

> - better resource key names to save space.
> Currently, the way to represent combined images is very wasteful:
> Couldn't this:
>  "qx/decoration/Modern/shadow/shadow-small-r.png": [5, 136, "png",
> "qx", "qx/decoration/Modern/shadow-small-lr-combined.png", 0, 0],
> be transformed to something like this:
> "qx/decoration/Modern/shadow/": {
>     "shadow-small-r.png": [5, 136, "png", "qx", "small-lr-combined.png", 0, 0],
>  

This wouldn't be general enough since the paths of image and combined
image need not share a lot. But in general I agree, the resource
representation could use some optimization.

> - better translations key names to save space
> As for resource names, it is currently very wasteful and almost ridiculous:
> Couldn't this
>
> "cldr_month_abbreviated_11": "Nov", "cldr_month_abbreviated_10": "Oct", ...
>
> be changed to something like this:
>
> "month": {
>     "abbreviated": {
>          10: "Oct",
>          11: "Nov",
>          ...
>
>  

Yep, that's on our list.

> - newline stripping
>  

see above.

> I think this used to be possible with the 0.7 build system, but I
> can't find a way to enable this in 0.8.
>
> - not "optimizing" string literals that are used only once.
>  

Not sure about this.

> - optimization of class names.
>  

This is part of the existing optimization already, if I'm not mistaken.

> - removal of unused code (methods).
>  

This is pretty fragile in a dynamic language, as you sure know.

> - automatic inlining of code if space is saved. Could possibly also
> add a configurable speed/space tradeoff factor: "inline even if
> resulting code is X larger".
>  

Yep, but this would require a major investment in our compiler backend.

Thomas

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Build version optimizations

thron7
In reply to this post by Gaetan de Menten


>> Dreamland
>> =========
>>
>> - automatic inlining of code if space is saved. Could possibly also
>> add a configurable speed/space tradeoff factor: "inline even if
>> resulting code is X larger".
>> This would save quite some space *and* make the code run faster.
>>    
>
> I'd really love to see this kind of feature. Unfortunately, I guess
> this is too hard to achieve by Qooxdoo developers alone. This makes me
> think: couldn't the "minifier" part of the build process be released
> as a standalone tool so that we can pool the effort of minizing code
> with other projects? With the rise of developing applications on the
> web, there should be more and more people interested in such
> technologies.
>
>  

Actually, I think that's a worthwhile thing to think about. I see some
potential to turn both the compiler and the generator into separate or
dedicated sub-projects.

T.


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Build version optimizations

Gaetan de Menten
In reply to this post by thron7
On Mon, Oct 13, 2008 at 12:47 PM, thron7 <[hidden email]> wrote:

>> - not "optimizing" string literals that are used only once.
>
> Not sure about this.

For example, this seems wasteful to me:

(function(){var a="pinte.datastore.Item";
qx.Class.define(a,
{extend:qx.core.Object,
construct:function(b){arguments.callee.base.call(this);
this.model=b;
},
members:{load:function(){}}});
})();

and would probably be better as:

qx.Class.define("pinte.datastore.Item",
{extend:qx.core.Object,
construct:function(b){arguments.callee.base.call(this);
this.model=b;
},
members:{load:function(){}}});

>> - optimization of class names.
>
> This is part of the existing optimization already, if I'm not mistaken.

It is not. At least, not in the sense I described above. Or maybe it's
not on by default AND not documented anywhere?

>> - removal of unused code (methods).
>
> This is pretty fragile in a dynamic language, as you sure know.

Well, it's hard (read: almost impossible) to tell whether a particular
piece of code (say an "if" block) will actually be executed, but there
*are* cases where you can tell with confidence (you can't be
fancy-programming-proof, that's true) that a method is never executed:
if there is *zero* occurence of the method name anywhere in the code,
you can pretty reliably assume it's not executed. In qooxdoo, I was
more specifically thinking about methods in static classes: not all of
them are used. For example: qx.lang.Object.carefullyMergeWith is
included but not used anywhere in the framework nor in my own code, so
will never be called.

--
Gaëtan de Menten
http://openhex.org

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Build version optimizations

Hugh Gibson-2
> >> - optimization of class names.
> >
> > This is part of the existing optimization already, if I'm not
> > mistaken.
>
> It is not. At least, not in the sense I described above. Or maybe
> it's not on by default AND not documented anywhere?

It *is* an existing bug - http://bugzilla.qooxdoo.org/show_bug.cgi?id=433
- but no action has been taken on it as far as I know.

Hugh

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Build version optimizations

Jim Hunter
In reply to this post by Gaetan de Menten
Your assuming that if you can't find the name of a method in the class code you provide, then it's not used and can be removed is simply not true. If the compiler did that to me I would scream. I have dynamically generated code on the server that makes calls against my library classes. The generated code may hit classes & methods that are not referenced anywhere else in my code.

So I would vote to never have the compiler simply remove code that it thinks is not used, for me it's just not safe or accurate.

Jim


On Mon, Oct 13, 2008 at 4:15 AM, Gaetan de Menten <[hidden email]> wrote:
On Mon, Oct 13, 2008 at 12:47 PM, thron7 <[hidden email]> wrote:

>> - not "optimizing" string literals that are used only once.
>
> Not sure about this.

For example, this seems wasteful to me:

(function(){var a="pinte.datastore.Item";
qx.Class.define(a,
{extend:qx.core.Object,
construct:function(b){arguments.callee.base.call(this);
this.model=b;
},
members:{load:function(){}}});
})();

and would probably be better as:

qx.Class.define("pinte.datastore.Item",
{extend:qx.core.Object,
construct:function(b){arguments.callee.base.call(this);
this.model=b;
},
members:{load:function(){}}});

>> - optimization of class names.
>
> This is part of the existing optimization already, if I'm not mistaken.

It is not. At least, not in the sense I described above. Or maybe it's
not on by default AND not documented anywhere?

>> - removal of unused code (methods).
>
> This is pretty fragile in a dynamic language, as you sure know.

Well, it's hard (read: almost impossible) to tell whether a particular
piece of code (say an "if" block) will actually be executed, but there
*are* cases where you can tell with confidence (you can't be
fancy-programming-proof, that's true) that a method is never executed:
if there is *zero* occurence of the method name anywhere in the code,
you can pretty reliably assume it's not executed. In qooxdoo, I was
more specifically thinking about methods in static classes: not all of
them are used. For example: qx.lang.Object.carefullyMergeWith is
included but not used anywhere in the framework nor in my own code, so
will never be called.

--
Gaëtan de Menten
http://openhex.org

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel



--
Jim Hunter

DAILY THOUGHT: SOME PEOPLE ARE LIKE SLINKIES - NOT REALLY GOOD
FOR  ANYTHING BUT THEY BRING A SMILE TO YOUR FACE WHEN PUSHED DOWN THE STAIRS

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Build version optimizations

Gaetan de Menten
On Mon, Oct 13, 2008 at 8:08 PM, Jim Hunter <[hidden email]> wrote:

> Your assuming that if you can't find the name of a method in the class code
> you provide, then it's not used and can be removed is simply not true. If
> the compiler did that to me I would scream. I have dynamically generated
> code on the server that makes calls against my library classes. The
> generated code may hit classes & methods that are not referenced anywhere
> else in my code.
>
> So I would vote to never have the compiler simply remove code that it thinks
> is not used, for me it's just not safe or accurate.

Your case might not be everybody's needs. I'd think not so many people
provide code after the initial payload. And of course, as with all the
other optimizations, it would need to be provided as an option. But we
are talking about a very hypothetical feature anyway, so no need to
get "upset" already.

--
Gaëtan de Menten
http://openhex.org

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Build version optimizations

Fabian Jakobs
Administrator
In reply to this post by Gaetan de Menten
Hi Gaetan,

see my inline comments ....
>> - not "optimizing" string literals that are used only once.
>>
>> There are lot of those and this waste space and possibly a bit of load time.
>>    
This should be trivial to implement but is important to note that the
string optimizer severs two purposes:

1. saving space
2. optimizing IE6 performance. This was the initial reason for this
optimization. This helps specially if a string is used in a loop. In
this case the string should be optimized even if it is the only occurrence.

>> Could do but probably hard
>> ======================
>>
>> - optimization of protected/public method and variable names.
>>    
This is already implemented for privates. Protected methods/variables
are a lot harder because they require an global code analysis. It is
however a possible optimization.
>> - optimization of class names.
>>    
>
> The most effective way would be to do it cross-namespaces: for
> example, renaming qx.ui.form.Spinner to "a1", qx.io.remote.Request to
> "a2", etc...
> Of course, names should be allocated on a shorter names go to names
> with more occurences. This would save tons of space I think.
>  
I think this could be done although one has to be very careful to not
change any semantics. But this is on the other hand exactly the code,
which can be easily compressed by gzip. If you are serving the
application with gzip compression I don't expect much difference with
this optimization enabled.

>  
>> - removal of unused code (methods).
>>    
>
> I noticed that unused methods gets included in the build version. I
> have a couple methods in my classes that are only used for debugging,
> but even if I comment the calls to those methods, the definition of
> the methods gets included. I'm not sure how much such a mechanism
> would save but I bet there is a substential part of the code which is
> never used (either directly or indirectly -- ie it is used only by
> other code which is itself not used). A tiny example is all the
> "abstract" methods which contain some error message.
>  
This is my favourite :-) We have talked about this optimizations several
times in our team but always dismissed it. The dynamic nature of
JavaScript makes it virtually impossible to exactly determine, which
methods gets called. Just some common examples:

funcation(a) {
    a.hide();     // <- which hide methods gets called?
}

var o = qx.lang.Object;
o.carefullyMergeWith(a, b);   // <-- we need type inference to catch
this one


a = "foo"
c[a]();   // <-- calling a method this way is a common way to avoid "eval"


The only pragmatic option to remove unused methods is a white list
approach. In the end the developer is the only one who can decide, which
code is actually used. We could add a list of methods to remove to the
"config.json".


>  
>> Dreamland
>> =========
>>
>> - automatic inlining of code if space is saved. Could possibly also
>> add a configurable speed/space tradeoff factor: "inline even if
>> resulting code is X larger".
>> This would save quite some space *and* make the code run faster.
>>    
>
> I'd really love to see this kind of feature. Unfortunately, I guess
> this is too hard to achieve by Qooxdoo developers alone. This makes me
> think: couldn't the "minifier" part of the build process be released
> as a standalone tool so that we can pool the effort of minizing code
> with other projects? With the rise of developing applications on the
> web, there should be more and more people interested in such
> technologies.
>  
Inlining is a very effective performance improvement. GWT added inlining
support to 1.5 and there are reports of up to 50% speed improvements for
special code. The difference to qooxdoo is that they are optimizing a
statically typed langugage (Java) while we have to deal with the very
dynamic JavaScript. I can imagine some places where we might be able to
know which method is called and inline its body. Note that we still
can't remove the original method unless we are 100% sure it isn't used
somewhere else.
It might be worth investigating but this is probably nothing the core
team will spend much time on but it could make an interesting
Diploma/Master/Bachelor Thesis.

I like the idea to split the tooling from the framework but right now
only a small part of the tools will work with any other JavaScript
library. The linker and many optimization steps need some deep knowledge
of the way qooxdoo classes are defined.


Best Fabian



--
Fabian Jakobs
JavaScript Framework Developer

1&1 Internet AG
Brauerstraße 48
76135 Karlsruhe

Amtsgericht Montabaur HRB 6484

Vorstand: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Thomas Gottschlich, Matthias Greve, Robert Hoffmann, Markus Huhn, Oliver Mauss, Achim Weiss
Aufsichtsratsvorsitzender: Michael Scheeren


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Build version optimizations

Fabian Jakobs
Administrator
In reply to this post by Gaetan de Menten
Gaetan de Menten schrieb:

> Hello again,
>
> I've looked at what gets generated by a ./generate build of my
> application and I think there is room for much improvement. Is any of
> the following (sorted from easy to hard) planned?
>
> Should do (IMO)
> =============
>
> - loader code optimization: the "part loader" code, seem to not be
> optimized at all: it contains comments, indentation, etc... Besides,
> it "leaks", the global variable "isMshtml" (ie a variable not in the
> qooxdoo namespace): is it intended or an oversight?
>  
Thanks for the "isMshtml" hint. I have fixed the loader to no longer
leak this variable.

Best Fabian


--
Fabian Jakobs
JavaScript Framework Developer

1&1 Internet AG
Brauerstraße 48
76135 Karlsruhe

Amtsgericht Montabaur HRB 6484

Vorstand: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Thomas Gottschlich, Matthias Greve, Robert Hoffmann, Markus Huhn, Oliver Mauss, Achim Weiss
Aufsichtsratsvorsitzender: Michael Scheeren


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Build version optimizations

Gaetan de Menten
In reply to this post by Fabian Jakobs
On Tue, Oct 14, 2008 at 9:58 AM, Fabian Jakobs <[hidden email]> wrote:

>>> - not "optimizing" string literals that are used only once.
>>>
>>> There are lot of those and this waste space and possibly a bit of load time.
>>>
> This should be trivial to implement but is important to note that the
> string optimizer severs two purposes:
>
> 1. saving space
> 2. optimizing IE6 performance. This was the initial reason for this
> optimization. This helps specially if a string is used in a loop. In
> this case the string should be optimized even if it is the only occurrence.

I didn't know that. Thanks for the clarification.

>>> Could do but probably hard
>>> ======================
>>>
>>> - optimization of class names.
>>>
>>
>> The most effective way would be to do it cross-namespaces: for
>> example, renaming qx.ui.form.Spinner to "a1", qx.io.remote.Request to
>> "a2", etc...
>> Of course, names should be allocated on a shorter names go to names
>> with more occurences. This would save tons of space I think.
>>
> I think this could be done although one has to be very careful to not
> change any semantics. But this is on the other hand exactly the code,
> which can be easily compressed by gzip. If you are serving the
> application with gzip compression I don't expect much difference with
> this optimization enabled.

It's true the savings do not end up being linear, but it'd still
impact the size significantly.
Here is a quick test by replacing qx.* and pinte.* (my app namespace)
by a 5 char string (this is pretty conservative replacement).

before: 757056
after: 696676
= 8% saved

Gzipped:
before: 191888
after: 181188
= 6% saved

The savings are not as much as I had hoped, and a real algorithm might
get slightly less savings when gzipped as I used only 2 different 5
char strings, which probably compressed "too well" by gzip, but I
don't think it'd differ by more than a percent.

--
Gaëtan de Menten
http://openhex.org

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Build version optimizations

Hugh Gibson-2
In reply to this post by Fabian Jakobs
> > The most effective way would be to do it cross-namespaces: for
> > example, renaming qx.ui.form.Spinner to "a1",
> > qx.io.remote.Request to
> > "a2", etc...
> > Of course, names should be allocated on a shorter names go to
> > names
> > with more occurences. This would save tons of space I think.
> >  
> I think this could be done although one has to be very careful to
> not change any semantics. But this is on the other hand exactly the
> code, which can be easily compressed by gzip. If you are serving
> the application with gzip compression I don't expect much
> difference with this optimization enabled.

Saving not just space but lookup time for multiple dictionaries. a.b.c.d
is four lookups - a13 is just one.

Hugh

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Build version optimizations

Fabian Jakobs
Administrator
Hugh Gibson schrieb:

>>> The most effective way would be to do it cross-namespaces: for
>>> example, renaming qx.ui.form.Spinner to "a1",
>>> qx.io.remote.Request to
>>> "a2", etc...
>>> Of course, names should be allocated on a shorter names go to
>>> names
>>> with more occurences. This would save tons of space I think.
>>>  
>>>      
>> I think this could be done although one has to be very careful to
>> not change any semantics. But this is on the other hand exactly the
>> code, which can be easily compressed by gzip. If you are serving
>> the application with gzip compression I don't expect much
>> difference with this optimization enabled.
>>    
>
> Saving not just space but lookup time for multiple dictionaries. a.b.c.d
> is four lookups - a13 is just one.
>  
Yes that's right. It we get to implement it it will probably be more
because of the potential speedup.

Best Fabian



--
Fabian Jakobs
JavaScript Framework Developer

1&1 Internet AG
Brauerstraße 48
76135 Karlsruhe

Amtsgericht Montabaur HRB 6484

Vorstand: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Thomas Gottschlich, Matthias Greve, Robert Hoffmann, Markus Huhn, Oliver Mauss, Achim Weiss
Aufsichtsratsvorsitzender: Michael Scheeren


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel