[DHTML] Performance vraag

[André]

Vraag 1: Wat is sneller om een array van 4 waarden te checken:

JavaScript:

if ((AF[0].y == 348) || (AF[1].y == 348) || (AF[2].y == 348) || (AF[3].y == 348)) { bla }

of met een lus:

JavaScript:

for (i=0; i<4; i++)
{
  if (AF[i].y == 348) { bla }
}

Vraag 2: Is het sneller om in een lus de if statements bij elkaar te zetten of te splitsen:

JavaScript:

for (i=0; i< array.length; i++)
{
  if (bla == 1)
  {
    if (bla == 2)
    {
      if (bla == 3)
      {
        bla
      }
    }
  }
}

Of:

JavaScript:

for (i=0; i< array.length; i++)
{
  if ((bla == 1) && (bla == 2) && (bla == 3)) { bla }
}

Hebben mensen hier ervaring mee

[crisp]

Vraag 1: de 1e want je hoeft geen teller bij te houden (maar is minder flexibel)
Vraag 2: de 2e heeft iets minder overhead voor de parser, maar dat is denk ik te verwaarlozen...

edit: @vraag 1 moet je wel uit je lus springen als aan de conditie voldaan wordt, anders is het niet identiek

als je trouwens met vergelijkingen werkt is de strict equal operator (===) sneller dan de gewone equal operator (==); je moet dan echter wel zeker zijn van het type van je variabelen.

en dit is ook sneller:

JavaScript:

var i = 0;
do {
  if ((bla == 1) && (bla == 2) && (bla == 3)) { bla }
} while (++$i < array.length);

als je zeker weet dat je array 1 of meer elementen bevat scheelt het je namelijk 1 afvraging

[ Voor 81% gewijzigd door crisp op 18-07-2003 01:20 ]

[André]

crisp schreef op 18 July 2003 @ 01:12:
Vraag 1: de 1e want je hoeft geen teller bij te houden (maar is minder flexibel)
Vraag 2: de 2e heeft iets minder overhead voor de parser, maar dat is denk ik te verwaarlozen...

edit: @vraag 1 moet je wel uit je lus springen als aan de conditie voldaan wordt, anders is het niet identiek

als je trouwens met vergelijkingen werkt is de strict equal operator (===) sneller dan de gewone equal operator (==); je moet dan echter wel zeker zijn van het type van je variabelen.

en dit is ook sneller:

JavaScript:

var i = 0;
do {
  if ((bla == 1) && (bla == 2) && (bla == 3)) { bla }
} while (++$i < array.length);

als je zeker weet dat je array 1 of meer elementen bevat scheelt het je namelijk 1 afvraging

Ik weet zeker dat de Array 4 elementen bevat (tetris figuurtje )

En over die === heb ik wel es wat gehoord, dat kan zeker alleen als ik bijvoorbeeld strings met string vergelijk enz.?

Edit:
En die ++$i dan, waar komt dat weg, daar heb ik nog nooit van gehoord.

[ Voor 5% gewijzigd door André op 18-07-2003 01:28 ]

[crisp]

André schreef op 18 July 2003 @ 01:23:
[...]

Ik weet zeker dat de Array 4 elementen bevat (tetris figuurtje )

En over die === heb ik wel es wat gehoord, dat kan zeker alleen als ik bijvoorbeeld strings met string vergelijk enz.?

yep:

JavaScript:

var a = '1';
var b = 1;
if (a == b);  // true
if (a === b);  // false

var c = false;
var d = 0;
if (c);  // false
if (d);  // false
if (c === false);  // true
if (d === false);  // false

[ Voor 15% gewijzigd door crisp op 18-07-2003 01:32 ]

[Clay]

who als ik vraag 1 in een benchmark test is de for loop 2x zo traag de 2e scheelt zo'n tien procent. && ... && snelst, wat crisp al zei.

[crisp]

André schreef op 18 July 2003 @ 01:23:
[...]
Edit:
En die ++$i dan, waar komt dat weg, daar heb ik nog nooit van gehoord.

Dat is een pre-increment; in vergelijkingen wordt dan zeg maar eerst de increment uitgevoerd en daarna pas de evaluatie; itt een postincrement (i++) waarbij eerst de evaluatie wordt uitgevoerd en daarna pas de increment:

JavaScript:

var i = 3;
if (i++ === 4);  // false
alert(i); // 4

if (++i === 5);  // true
alert(i);  // 5

edit: ik zie nu pas dat ik i en $i door elkaar heen aan het gebruiken ben

[ Voor 8% gewijzigd door crisp op 18-07-2003 09:34 ]

[Devilfish]

Clay schreef op 18 juli 2003 @ 09:08:
who als ik vraag 1 in een benchmark test is de for loop 2x zo traag de 2e scheelt zo'n tien procent. && ... && snelst, wat crisp al zei.

&& && is sneller omdat ie de rest(de rechterzijde van de een item) van de boolean vergelijking niet meer hoeft te doen. Dus als de de tweede al true is hoeft ie de anderen niet meer uit te voeren. (want de or wordt dan zowiezo al true)

[Bosmonster]

Devilfish schreef op 18 July 2003 @ 09:39:
[...]


&& && is sneller omdat ie de rest(de rechterzijde van de een item) van de boolean vergelijking niet meer hoeft te doen. Dus als de de tweede al true is hoeft ie de anderen niet meer uit te voeren. (want de or wordt dan zowiezo al true)

Dat lijkt me juist omgekeerd Als die && moet doen MOET ie ze dus allemaal checken. Bij een || kan die bij de eerste match stoppen en dat doet Javascript dus ook.

De eerste mogelijkheid uit vraag 1 zou dus in theorie de snelste moeten zijn.

[crisp]

Devilfish schreef op 18 juli 2003 @ 09:39:
[...]
&& && is sneller omdat ie de rest(de rechterzijde van de een item) van de boolean vergelijking niet meer hoeft te doen. Dus als de de tweede al true is hoeft ie de anderen niet meer uit te voeren. (want de or wordt dan zowiezo al true)

Vandaar mijn opmerking dat je uit de loop moet springen zodra de vergelijking waar is; anders is het niet hetzelfde als de OR constructie:

JavaScript:

for (i=0; i<4; i++) {
  if (AF[i].y == 348) {
    bla();
    break;
  }
}

[Verwijderd]

Inderdaad Clay en Devilfish. Zoals Crisp in de tweede post al vertelde: je moet wel uit de loop springen, anders zijn zijn de codes niet identiek.

Clay, zou je misschien je test nog eens willen doen?

-- edit

Enigzins te laat.

[ Voor 8% gewijzigd door Verwijderd op 18-07-2003 11:03 . Reden: Ieks.. te laat :( ]

[Clay]

De && kan juist meteen stoppen als die iets tegenkomt wat niet klopt, de || gaat verder zodra er iets wel goed is.

Of de een trager is dan de ander hangt van je code af. De eerste match is voor de || genoeg, maar de eerste misser is voor de && genoeg. Met de loop moet je op de match idd wel eruit springen, maar waar die match tegengekomen wordt is afhankelijk van de run, dat kan de eerste iteratie zijn, of de laatste, net als met de || en &&.
Voor benchmarken maakt dat dus niet uit, want je moet er dan geeneen laten matchen zodat ze allemaal evenveel checks uitvoeren.

[ Voor 11% gewijzigd door Clay op 18-07-2003 11:46 ]

[Bosmonster]

Edit:

Het maakt eigenlijk niet uit dus.. .bij && kan die direct stoppen bij een false en bij || kan die direct stoppen bij een true

[ Voor 196% gewijzigd door Bosmonster op 18-07-2003 12:00 ]

[Verwijderd]

Geloof het of niet, maar dit

JavaScript:

for(var i=iLength-1; i>=0; i--) {}

// is tot 2x zo sneller dan dit:
for(var i=0; i<iLength; i++) {}

Als je nog eens echt in JS performance optimalizatie wil duiken:
http://home.earthlink.net...nfo/js_opt/jsOptMain.html

Veel informatie over unrolled loops, enzo.

[Bosmonster]

var i=iLength-1; i>=0;

Doe dan gewoon

var i=iLength; i>0

scheelt je weer een aftreksommetje

[André]

Verwijderd schreef op 18 July 2003 @ 14:46:
Geloof het of niet, maar dit

JavaScript:

for(var i=iLength-1; i>=0; i--) {}

// is tot 2x zo sneller dan dit:
for(var i=0; i<iLength; i++) {}

Als je nog eens echt in JS performance optimalizatie wil duiken:
http://home.earthlink.net...nfo/js_opt/jsOptMain.html

Veel informatie over unrolled loops, enzo.

Dus het achterwaarts doorlopen van een reeks (array) is sneller dan voorwaarts, shit he, hoe raar kan het zijn

[Verwijderd]

Bosmonster schreef op 18 July 2003 @ 15:20:
scheelt je weer een aftreksommetje

JavaScript:

// 1 aftreksommetje
for(var i=iLength-1; i>=0; i--) {
    alert(myArray[i]);
}

// iLength-1 aftreksommetjes:
for(var i=iLength; i>0; i--) {
    alert(myArray[i-1]);
}

Scheelt bij mij toch iLength - 2 aftreksommetjes

André schreef op 18 July 2003 @ 15:49:
Dus het achterwaarts doorlopen van een reeks (array) is sneller dan voorwaarts, shit he, hoe raar kan het zijn

Theorie is: het is sneller om een getal te vergelijken met 0 dan met een ander getal...

[ Voor 29% gewijzigd door Verwijderd op 18-07-2003 15:51 ]

[Bosmonster]

Ow ja .. dat omgekeerd rekenen is nog best lastig

[André]

Verwijderd schreef op 18 July 2003 @ 15:50:
[...]

Theorie is: het is sneller om een getal te vergelijken met 0 dan met een ander getal...

Ik lees het net....

Ik zie nu ook dingen waar ik veel aan heb in mijn game