Hi Guys,
I have more interesting idea of optimization in qooxdoo, but I don't
know if it's possible to implement. Javascript is dynamic language and
everything is determined at runtime, qooxdoo has complete namespace
system (and my app too) that forces you to write code like this:
qx.Class.define("qx.ui.table.Table", {...});
...
var instance = new qx.ui.table.Table();
...
The problem is that javascript first finds qx, then it looks for ui,
for table and for Table. I think that this can be optimized like this
way (by generator, not humans!):
var smc1, ...
...
smc1 = qx.Class.define("qx.ui.table.Table", {...});
...
var instance = new smc1();
Of course making variable 'smc1' (some minimized class) in local
(private) scope, look at generated version if interested about how it
works.
This idea will minimize code size, because size of symbol
qx.ui.table.Table will be minimized (to max 4 char symbol) and also
performance (in this case 4x for get Table class), because you
instantiate class directly, without interpreting qx.ui.table.Table.
Is this idea to be known here?
- Petr
2009/9/29 Fritz Zaucker <zauc...@oetiker.ch>:
> On Tue, 29 Sep 2009, A.Yerenkow wrote:
>
>> On 29.09.2009 9:26, Fritz Zaucker wrote:
>>> Hi Gene,
>>>
>>> you are right, I should stay consistent with the code examples to be sure
>>> there are no subtle differences. I found:
>>>
>>> - for (i=0, len=d.length; i<len); i++) {}
>>>
>>> and
>>>
>>> len = d.length;
>>> for (i=0; i<len); i++) {}
>>>
>>> give exactly identical execution times.
>>>
>>> - Funny enough
>>>
>>> var len = d.length;
>>> for (i=0; i<len); i++) {}
>>>
>>> is slightly slower, I am not sure, why this would be.
>>>
>> maybe because in prev examle 'len' is global while here it's local, I
>> can't think of other reason :)
>
> That's probably the explanation.
>
>>> I made another test that might be more useful:
>>>
>>> a) var k, n = 5000000;
>>> var d=[];
>>> for (k=0; k<n; k++) {
>>> d[k] = k;
>>> }
>>>
>>> b) var k, n = 5000000;
>>> var d=new Array(n);
>>> for (k=0; k<n; k++) {
>>> d[k] = k;
>>> }
>>>
>>> c) var k, n = 5000000;
>>> var d=[];
>>> for (k=0; k<n; k++) {
>>> d.push(k);
>>> }
>>>
>>> d) var k, n = 5000000;
>>> var d=[];
>>> d[n]=n;
>>> for (k=0; k<n; k++) {
>>> d[k] = k;
>>> }
>>>
>>> and found the following results with FF 3.5.3:
>>>
>>> a) 320 msecs
>>> b) 310 msecs
>>> c) 590 msecs
>>> d) 5641 msecs
>>>
>>> I did not expect d) being so bad, in fact I expected it to be faster than
>>> a) and similar to b)!
>
>> You could find info in internet about why is that :)
>
> I am sure ... for the moment I am pretty happy to know what to avoid ... ;-)
>
> I did actually try the various options I posted because of some
> recommendations I found with Google on JS loop optimisation.
>
> The one thing missing in these discussions was the diminishing effect once
> you actually do something inside the loop. And I just did a simple
> calculation. I am sure once you start accessing (DOM) objects, the effect of
> the control structure optimisation will disappear almost completly.
>
>> The javascript arrays aren't arrays at all :)
>
> To see the whole picture, try reverse tests, like this:
>
>> a) var k, n = 5000000;
>> var d=[];
>> for (k=n; k>0; k--) {
>> d[k] = k;
>> }
>>
>> .....
>>
>> d) var k, n = 5000000;
>> var d=[];
>> d[n]=n;
>> for (k=n; k>0; k--){
>> d[k] = k;
>> }
>>
>> e) var k, n = 5000000;
>>
>> var d=[];
>> d[0]=0;
>> for (k=n; k>0; k--){
>> d[k] = k;
>> }
>
> I'll do that later today and will post the results.
>
>> But anyway, I think if something could be used in qooxdoo
>> optimising/packing mechanisms - would be great :)
>
> Perhaps. Although, as I said, these simple optimisations might not give all
> that much benefit.
>
> Cheers,
> Fritz
>
>>> Anyhow, push() is relatively expensive compared to direct assignment to the
>>> last+1 index of an array. That's probably something to watch out for.
>>>
>>> Cheers,
>>> Fritz
>>>
>>> On Mon, 28 Sep 2009, Gene Amtower wrote:
>>>
>>>
>>>> Nice insight, Fritz.
>>>>
>>>> I noticed that in your first test discussion, you showed an example
>>>> where "len" was calculated prior to the loop structure, but later you
>>>> included it in the loop initialization structure itself. Not knowing
>>>> anything about the inner workings of JS, is there a chance that moving
>>>> it inside of the loop initialization might have negated some of the
>>>> improvement by causing some type of variable reference to be used
>>>> instead of a local variable value being created?
>>>>
>>>> Just wondered if you considered that minor detail and verified that your
>>>> example B has the same gains as the latter suggestion when there is no
>>>> internal statements in the loop, to avoid confusing the effect of the
>>>> calculation in the loop with this minor code change in the variable
>>>> initialization. Minor changes can sometimes affect how a language
>>>> references variable values, depending on how things work in the code
>>>> engine.
>>>>
>>>> Gene
>>>>
>>>> On Mon, 2009-09-28 at 21:54 +0200, Fritz Zaucker wrote:
>>>>
>>>>
>>>>> Hi,
>>>>>
>>>>> after having read some comments about loop optimization somewhere, I ran
>>>>> some very simple minded tests with JS for loops just loading the code
>>>>> directly from the file system and found on a Lenovo X60 with Ubuntu
>>>>> Jaunty:
>>>>>
>>>>> var d = [];
>>>>> d[50000000]=50000000;
>>>>>
>>>>> for (i=0; i<d.length); i++) {} // A
>>>>> len = d.length; for (i=0; i<d.length); i++) {} // B
>>>>>
>>>>>
>>>>> - B is more than 15% faster with FF3.5.3 and about 20% faster with Chrome
>>>>> 4.0.213.0 (Ubuntu build 26919)
>>>>>
>>>>> - Firefox 3.5.3 is about 3.5 times faster than Chrome
>>>>>
>>>>> - while and do/while loops are significantly faster than for loops in
>>>>> Chrome, but slower in FF.
>>>>>
>>>>> As the current SVN trunk of Qooxdoo has 877 type A loop statements in
>>>>> framework/source/class/qx/ I thought it might be worthwhile to change
>>>>> these
>>>>> loops from
>>>>>
>>>>> for (i=0; i<d.length); i++) {}
>>>>>
>>>>> to
>>>>>
>>>>> for (i=0, len=d.length; i<len); i++) {}
>>>>>
>>>>> where the array length doesn't change within the for loop.
>>>>>
>>>>> Thinking a bit further I figured that the performance gain might be
>>>>> marginal
>>>>> for any significant amount of code inside the loop. And indeed, adding
>>>>> just
>>>>> the simple line
>>>>>
>>>>> r = n*33;
>>>>>
>>>>> inside the loop made the difference in the for loops disappear, even for
>>>>> n=0
>>>>> ...
>>>>>
>>>>> So, I guess, measuring when trying to optimize for performance makes a lot
>>>>> of sense ... and just optimizing the control structure of a look doesn't
>>>>> gain that much. So the code inside the loop is where to search for
>>>>> improvements.
>>>>>
>>>>> Not really a very deep insight, but I thought I want to share this with
>>>>> you
>>>>> anyway, as these kinds of "urban coding myth" come up every once in a
>>>>> while.
>>>>>
>>>>> Cheers,
>>>>> Fritz
>
> --
> Oetiker+Partner AG tel: +41 62 775 99 03 (direct)
> Fritz Zaucker +41 62 775 99 00 (switch board)
> Aarweg 15 +41 79 675 06 30 (mobile)
> CH-4600 Olten fax: +41 62 775 99 05
> Schweiz web: www.oetiker.ch
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> qooxdoo-devel mailing list
> qooxdoo-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
