Was ist schneller? If oder Switch/Case
-
Original erstellt von Helium:
printf() ist eine externe Funktion und in C kann man Funtkionen nicht überladen.aber es ist dem compiler überlassen wie er die standardlib implementiert... d.h. er kann aus diesen aufrufen machen was er will solange sie ihre aufgabe erfüllen...
-
Original erstellt von Cocaine:
Ein ASM-Block im Code ist auf jeden Fall schneller als ein Funktionsaufruf von strlen(), bei dem die Prefetch-Queue gelöscht wird (spitzfindig, ich weiß
). Außerdem wird ja noch der Stackrahmen erstellt, kostet auch 'n paar Takte...Schonmal von inline gehört?
-
Original erstellt von Cocaine:
Ein ASM-Block im Code ist auf jeden Fall schneller als ein Funktionsaufruf von strlen(), bei dem die Prefetch-Queue gelöscht wird (spitzfindig, ich weiß ). Außerdem wird ja noch der Stackrahmen erstellt, kostet auch 'n paar Takte...Ein Assemblerblock hat aber folgende Probleme:
a) Du schaltest dir damit quasi den Optimierer ab (s.u.).
b) Dein Programm wird auf den meisten Plattformen (auf denen es noch compiliert) grösser, weil du die Möglichkeit ignorierst, Funktionen einer Bibliothek zu nutzen.
c) Portabilität.IMHO darf strlen (als Funktion der Standardbibliothek, über das der Compiler (fast) unbegrenztes Wissen hat/haben kann/haben darf) die Länge des strings einfach nur "wissen". Das machen manche Compiler, wenn du strlen auf ein Stringliteral anwendest.
Was genau bei einem Funktionsaufruf passiert ist hochgradig systemabhängig (Was z.B. bei Systemen ohne Stack?) und damit Spekulation.
-
ALso Funktionen eh net (also eigentlich doch).
Nicht inline!
INTRINSIC!
Schon beim Borland3.1 waren so Dinge intrinsic. Das heißt wörtlich übersetzt "magische Magie vom zaubernden Compiler".
strlen wird zu nem funktionsaufruf von strlen (irgendwie in asm gebaut, handoptimiert, macht immer 4 bytes auf einmal, vorher alignemet richtigstellen damit schneller und so die komplette Trickkiste eben). Oder auch nicht. intrinsic-dinge kann der compiler verwursteln wie er will. ich erinnere mich darn, daß der compiler das memset (ebenfalls intrinsic) je nach speicherblockgröße gerne mal zu repne stosb macht. manchmal auch zu nem funktionsaufruf.
du kannst nur deshalb schneller werden, weiß di annahmen über die strings hast, z.b. daß alle kürzer als 15 zeichen sind. diese info zu verwerten ist aber sowohl in asm als auch in c++ erlaubt und erwünscht. so ganz allgemein und ohne infos zur datenlage ist ne funktion sicherlich sinnvoller.
-
hm.. bei else if springt der sofort raus auser ganzen Geschichte sobald der was gefunden hat ... bei case sicher auch..
Aber wenn du das genau wissen willst würdich mir mal assembler umwandlung von deinem Code anschaun und dann hübsch in ner Liste vergleichen(gibt da welche weiss nur grad keine url :D) wieviel der und der Befehl genaz genau braucht.. ich denk mal wenn optimierung drin ist "denkt" der Compiler eh soviel nach das der code sowieso so und so gleichschnell ist
-
gerne
-
Original erstellt von dukelc4:
**Hi,
weiß jemand welchen Schleife schneller bearbeitet wird?
Sowas: if (d[3] & 0x80) ...
if (d[3] & 0x81) ...Oder: Switch(d[3]{
case 0x80: ...
case 0x81: .......
**Hi,
wenn du sowas hast ist ein Feld von funktionen am besten.
Soll heißen so schreibst dir für jeden fall der eintreten kann eine Funktion:void case_080(...){...}
void case_081(...){...}
void case_082(...){...}
...
Die packst du dann in nen Array rein:void (*a[FUNC_ANZ])(...);
...
a[0]=case_080;
...Nun musst du noch ein wenig indexrechnung("deinAusdruck") machen, so dass auch die richtige Funktion aufgerufen wird ( soll heißen deine Überprüfung im switch/if teil auch richtig auf 0 bis FUNC_ANZ-1 abgebildet wird):
(*a["deinAusdruck"])(...);
Oder so...
[ Dieser Beitrag wurde am 18.02.2003 um 20:46 Uhr von xroads42 editiert. ]
-
wobei die relevanz von mikrosekunden hier bedeutet, dass switch oder if-else scheißegal ist :p
-
Stimmt, hier sind eher die Monate relevant, die der Thread alt ist
-
Kommt sehr drauf an wie oft solch eine Abfrage stattfindet und wieviele Verzweigungen es gibt. Da kann man mit switch schon einiges rausholen.