Topic awaiting preservation: Better for loops and Java/Javascript optimisation (Page 2 of 2)

Liorean: Welcome in the Asylum. For one of your first posts, that's a monster/master piece. Kudos.

Many of the simple loop optimization tricks covered here are also explained in "Speed up you site" by Andrew B. King ( ISBN: 0-7357-1324-3 ) ( though I've always found his resulting numbers were weird, but afair he tested his routines on a Mac ).

That's great to have the view of someone that really know how the JavaScript engines are implemented, all the more that you explanations are clear.

I didn't knew that the JavaScript engine(s) created a temporary array for the HTMLCollection, HTMLOptionsCollection, NodeList or NamedNodeMap. On the other hand I'm not surprised about how the variables are handled and by the fact that the numbers are stored in IEEE 754 in priority. Actually the way the variables are handled reminds me the way GFA basic handled them.

The poster has demanded we remove all his contributions, less he takes legal action.
We have done so.
Now Tyberius Prime expects him to start complaining that we removed his 'free speech' since this message will replace all of his posts, past and future.
Don't follow his example - seek real life help first.

Welcome, Liorean!

I had speculated as much concerning numbers being stored as floating point... the speed of number operations (divide especially) seemed such to me that it couldn't natively store everything as an integer.

The optimations are good to know, especially the one with caching getElementById etc., I was not aware of this behavior, personally.

Anyway, have a good stay at the Asylum!

"Any sufficiently advanced technology is indistinguishable from magic." -- Arthur C. Clarke
"Any sufficiently arcane magic is indistinguishable from technology." -- P. David Lebling

Actually, I have to correct myself about the DOMCollections. JavaScript has in difference to Java no threading support and as a single threaded language doesn't need to recreate the temporary arrays when accessing them in a loop. So,

var

    i=0,

    elm;

while(elm=document.getElementsByTagName(string).item(i++))

    dosomething;

is not at all faster than

var

    i=0,

    c=document.getElementsByTagName(string),

    elm;

while(elm=c.item(i++))

    dosomething;

Quite the opposite, actually, the latter example takes between five and ten or even a hundred times the amount of time to complete. (Opera has lousy preformance sometimes...)


I just put up a DOMCollection performance test that displays this. Especially Opera and MSN/OSX seems to benefit from caching the collections.



However, the rest of the optimisations are correct. Especially the last one mentioned is important. Comparing the counter to the collection length and accessing the element through the collection cancels out the benefit of caching the collection. So, the most important DOM optimisation for JavaScript (as opposed to Java) would be to use

var

    i=0,

    elm;

while(elm=coll.item(i++))

    dosomethingwithelm;

to traverse the collection instead of doing something like

var

    i=0,

    lenght=coll.length;

while(i++>l)

    dosomethingwithcoll[i];

or even worse

var

    i,

for(i=0;i<coll.length;i++)

    dosomethingwithcoll[i];

The short of it, cache everything you can, don't access an element by index in the collection if you can avoid it by caching it in the loop condition.
--
var Liorean = {
prototype: JavaScriptGuru.prototype,
abode: "http://liorean.web-graphics.com/",
profile: "http://codingforums.com/member.php?u=5798"};

(Edited by liorean on 09-15-2004 01:59)