Archief - Irritant extra spatie probleem

taLa. · 6 apr 2009

Misschien heeft hij het op die extra kopie die gebruikt wordt bij i++ om de oude waarde te returnen en die zogezegd voor slechtere performance zou zorgen? 'k Heb daar mensen wel al vaker over bezig gehoord, maar als ge daarmee begint zijt ge zo hard aan't micro-optimaliseren da't ni eens meer grappig is. Elke deftige compiler zal trouwens een i++ en ++i zonder assignment zoals in die for-loop naar dezelfde meest efficiënte vorm omzetten.

Disclaimer: enkel geldig voor ingebouwde datatypes. Voor bv. zware C++-klassen met een overloaded +-operator kan postfix of prefix wel degelijk een verschil maken.

Gurdt · 6 apr 2009

eigenlijk interessante dingen =D
en ja das idd vergezocht zulke dingen, maar fijn om eens over na te denken

Tyfius · 6 apr 2009

taLa. zei:
Misschien heeft hij het op die extra kopie die gebruikt wordt bij i++ om de oude waarde te returnen en die zogezegd voor slechtere performance zou zorgen? 'k Heb daar mensen wel al vaker over bezig gehoord, maar als ge daarmee begint zijt ge zo hard aan't micro-optimaliseren da't ni eens meer grappig is. Elke deftige compiler zal trouwens een i++ en ++i zonder assignment zoals in die for-loop naar dezelfde meest efficiënte vorm omzetten.

Disclaimer: enkel geldig voor ingebouwde datatypes. Voor bv. zware C++-klassen met een overloaded +-operator kan postfix of prefix wel degelijk een verschil maken.

Feit, uw compiler verwerkt dat meestal goed. Persoonlijk gebruik ik steeds "i++", al jaren en ik zie geen reden om dat anders te doen.

Wat ik wel grappig vind zijn mensen die bij hoog en bij laag "++i" gaan gebruiken omdat het performanter zou zijn maar dan in hun for loop wel een count gebruiken:

Code:

for ($i = 0; $i < count($array); ++$i) {}

SavaB · 7 apr 2009

taLa. zei:
Misschien heeft hij het op die extra kopie die gebruikt wordt bij i++ om de oude waarde te returnen en die zogezegd voor slechtere performance zou zorgen? 'k Heb daar mensen wel al vaker over bezig gehoord, maar als ge daarmee begint zijt ge zo hard aan't micro-optimaliseren da't ni eens meer grappig is. Elke deftige compiler zal trouwens een i++ en ++i zonder assignment zoals in die for-loop naar dezelfde meest efficiënte vorm omzetten.

Disclaimer: enkel geldig voor ingebouwde datatypes. Voor bv. zware C++-klassen met een overloaded +-operator kan postfix of prefix wel degelijk een verschil maken.

Ik doel idd op de extra kopie die wordt aangemaakt. Zowat alle standaarden drukken erop om dit te gebruiken (oa Sutter), simpelweg omdat dit een regel is die enorm simpel toe te passen valt, en toch altijd optimaler is dan i++. Dit valt voor hen dan ook niet onder optimalisatie, maar eerder onder leefregels waar je je gewoon best aan houdt...

killgore · 7 apr 2009

SavaB zei:
Ik doel idd op de extra kopie die wordt aangemaakt. Zowat alle standaarden drukken erop om dit te gebruiken (oa Sutter), simpelweg omdat dit een regel is die enorm simpel toe te passen valt, en toch altijd optimaler is dan i++. Dit valt voor hen dan ook niet onder optimalisatie, maar eerder onder leefregels waar je je gewoon best aan houdt...

En die compleet achterhaald zijn. We leven niet meer in de jaren '70 waar er geen sprake is van compileroptimalisatie he. Zoiets wordt door elke goede compiler weggeoptimaliseerd en is dus ver nooit optimaler.

Cycloon · 7 apr 2009

Tyfius zei:
Wat ik wel grappig vind zijn mensen die bij hoog en bij laag "++i" gaan gebruiken omdat het performanter zou zijn maar dan in hun for loop wel een count gebruiken:

Code:

for ($i = 0; $i < count($array); ++$i) {}

Hangt af van taal tot taal, sommige talen gaan dat telkens opnieuw evalueren, anderen niet.

SavaB · 7 apr 2009

voor built-in types helpt dat idd geen fuck, maar aangezien je niet altijd built-in types gaat gebruiken, maar ook eigen objecten waar je eventueel operator++ zou overloaden. Daarom is het gewoon een questie van goede gewoonte om toch altijd in een for-loop ++i te gebruiken.

killgore · 7 apr 2009

Cycloon zei:
Hangt af van taal tot taal, sommige talen gaan dat telkens opnieuw evalueren, anderen niet.

ehm, van de compiler dus. Als uw compiler zo slim is om te detecteren dat die count-functie altijd hetzelfde resultaat gaat geven zal hij die idd uitschakelen (wat in simpele gevallen zo is).

Anders mag em niet zomaar zeggen van we voeren dat maar 1X uit. Dat zou vrij fout & ongewenst gedrag zijn. Het kan evengoed zijn dat die count functie bij elke stap wijzigt.

Cycloon · 8 apr 2009

killgore zei:
ehm, van de compiler dus. Als uw compiler zo slim is om te detecteren dat die count-functie altijd hetzelfde resultaat gaat geven zal hij die idd uitschakelen (wat in simpele gevallen zo is).

Anders mag em niet zomaar zeggen van we voeren dat maar 1X uit. Dat zou vrij fout & ongewenst gedrag zijn. Het kan evengoed zijn dat die count functie bij elke stap wijzigt.

Elke compiler binnen een taal hoort hetzelfde te doen, ik had het echt over de taal zelf. Ok, het voorbeeld met de count() functie in PHP was mss niet het beste, maar zo zal bv perl methode oproepen nooit opnieuw evalueren in een forlus.

Tyfius · 8 apr 2009

Cycloon zei:
Elke compiler binnen een taal hoort hetzelfde te doen, ik had het echt over de taal zelf. Ok, het voorbeeld met de count() functie in PHP was mss niet het beste, maar zo zal bv perl methode oproepen nooit opnieuw evalueren in een forlus.

Nooit nooit, of als de inhoud niet veranderd?

Stel dat ik een lijst met gebruikers heb waar ik een bepaalde controle op moet doen en indien X aantal voorwaarden zijn voldaan een andere gebruiker moet toevoegen aan mijn lijst binnen die for-lus. Dan wil ik dat die nieuwe gebruiker ook geëvalueerd wordt.

killgore · 8 apr 2009

Cycloon zei:
Elke compiler binnen een taal hoort hetzelfde te doen, ik had het echt over de taal zelf. Ok, het voorbeeld met de count() functie in PHP was mss niet het beste, maar zo zal bv perl methode oproepen nooit opnieuw evalueren in een forlus.

Ik ken geen perl, maar als dat een klassieke for-lus is is dat fout. Het kan heel goed zijn dat die functie wel degelijk na elke iteratie een ander resultaat geeft.

Het kan wel zijn dat perl (net zoals python) optimalisaties heeft voor het lopen over ingebouwde collecties, waarbij counts enzo dan inderdaad vastgezet worden, maar dat is niet het gedrag van een klassieke for-lus.

Cycloon · 8 apr 2009

Tyfius zei:
Nooit nooit, of als de inhoud niet veranderd?

Nooit nooit kan ik niet met zekerheid zeggen, maar er zijn heel wat zaken die niet opnieuw geëvalueerd zullen worden, ook al verandert de inhoud. Dat moet je natuurlijk op voorhand weten als je met zo'n taal aan het werken gaat.

killgore zei:
Ik ken geen perl, maar als dat een klassieke for-lus is is dat fout. Het kan heel goed zijn dat die functie wel degelijk na elke iteratie een ander resultaat geeft.

"Klassiek", perl is toch wel iets apart op zich (wat het ook wel sterk maakt met momenten). Perl heeft nogal de neiging om bepaalde zaken die variabel zijn in bepaalde situaties te gaan uitschrijven als constanten (om het zo te zeggen) en daar moet je dan wel attent op zijn (vooral als je zaken gaat expanderen).

Gurdt · 9 apr 2009

Cycloon zei:
"Klassiek", perl is toch wel iets apart op zich (wat het ook wel sterk maakt met momenten). Perl heeft nogal de neiging om bepaalde zaken die variabel zijn in bepaalde situaties te gaan uitschrijven als constanten (om het zo te zeggen) en daar moet je dan wel attent op zijn (vooral als je zaken gaat expanderen).

hoe de fok kan da ooit goed zijn? een variabele is noemt zo omdat het variabel is....
trouwens, data staat in het geheugen en een variabele instantie neemt evenveel geheugen in als een constante instantie van iets, dus daar wordt geen voordeel uitgehaald

lijkt me sterk dat perl voordeel probeert te halen door opdrachten vn de programmeur te negeren...

Cycloon · 9 apr 2009

Voor de ongelovige thomassen:

Code:

$str="aaaaaa"
foreach my $i (0..(length($str)-1)) {
   if(substr($str,$i,1) eq "a") {
      substr($str,$i,1) = "bb";
   }
}

Equivalente c++ code:

Code:

string str="aaaaaa"
for(int i=0;i<str.length();i++)
   if(str.substr(i,1)=="a")
      str.replace(i,1,"bb");

Beiden geven een ander resultaat.

Perl: bbbbbbaaa
C++: bbbbbbbbbbbb

En dit komt enkel en alleen omdat perl de lengte van de string niet meer gaat evalueren, ook al wijzigt deze.

Bon, ik ben hier weer teveel moeite aan het doen.

forloRn_ · 9 apr 2009

Dat is niet equivalent. 't Eerste is een for-each, die gaat length() maar één keer evalueren, terwijl een gewone for-lus die conditie elke iteratie gaat evalueren.

Tyfius · 9 apr 2009

Inderdaad, want

Code:

$string = "aaaaaa";
for ($i = 0; $i < length($string); $i++) {
        if (substr($string, $i, 1) eq "a") {
                substr($string, $i, 1) = "bb";
        }
}

Geeft als resultaat:

Code:

jensen@atlantis:~/Desktop$ perl test.pl 
bbbbbbbbbbbb

Cycloon zei:
Bon, ik ben hier weer teveel moeite aan het doen.

Ik vind dit nu net interessante discussies

Cycloon · 9 apr 2009

forloRn_ zei:
Dat is niet equivalent. 't Eerste is een for-each, die gaat length() maar één keer evalueren, terwijl een gewone for-lus die conditie elke iteratie gaat evalueren.

Nope, het ligt niet aan de foreach maar aan het feit dat 0..length($string) gaat geëxpandeerd worden naar een lijst/array en dat niet telkens opnieuw gaat gedaan worden. Mocht dit wel zo zijn dan zou het normaal allemaal lopen zoals "verwacht" werd.

Bon, mijn punt was gewoon dat je in sommige situaties vreemde zaken kan tegenkomen en dat het taal afhankelijk is en niet compiler afhankelijk (zoals hier beweerd werd).

Gurdt · 10 apr 2009

dat was er wel ff tegen he cycloon :')
=D

Cycloon · 10 apr 2009

Gurdt zei:
dat was er wel ff tegen he cycloon :')
=D

Wat was er tegen? Dat ze ook een voorbeeld hebben gegeven waar het wel goed gaat?

Kindje toch

Gurdt · 10 apr 2009

Cycloon zei:
Wat was er tegen? Dat ze ook een voorbeeld hebben gegeven waar het wel goed gaat?

Kindje toch

dat heel uw punt kapot is

Archief - Irritant extra spatie probleem

taLa.

Legacy Member

Gurdt

Legacy Member

Tyfius

Legacy Member

SavaB

Legacy Member

killgore

Legacy Member

Cycloon

Legacy Member

SavaB

Legacy Member

killgore

Legacy Member

Cycloon

Legacy Member

Tyfius

Legacy Member

killgore

Legacy Member

Cycloon

Legacy Member

Gurdt

Legacy Member

Cycloon

Legacy Member

forloRn_

Legacy Member

Tyfius

Legacy Member

Cycloon

Legacy Member

Gurdt

Legacy Member

Cycloon

Legacy Member

Gurdt

Legacy Member