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
>
------------------------------------------------------------------------------
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
