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.
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)!
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
