Performance von switch

THX 1138

SideWinder schrieb:

Schlecht.

MfG SideWinder

Genau UN kannste Dir in den Arsch schieben!

volkard

SideWinder schrieb:

Wenn es wirklcih eine ganze Menge weiterer Aufrufe sind, schau, dass alle Funktionen die selbe Anzahl an Parametern haben.
Dann kannst du mit einem Array von Funktionspointern arbeiten und bin schneller als die Feuerwehr:

switch ist schneller als dein array.
bei switch sollte man natürlich darauf achten, daß die IDs bei 0 beginnen und fortlaufend sind, damit's von dem gleichen vortiele-tellerchen essen kann. außerdem tut ein default: __assume(false); auch ganz gut, wenn man sich's leisten kann (entspricht ungefähr dem assert(ID>=0 && ID<=MAXID)).
switch ist deswegen schneller, weils die kleinen funktionsaufrufe auch inline läßt und hier kann der optimierer zuschlagen.

switch wird fast immer mit einer Sprungtabelle (manchmal auch ein baum), aufgebaut, wodurch das suchen des passenden codes extrem schnell von statten geht

wenn du maximale performance willst, dann nimm ein switch und sorg dafür, dass die implementierung der funktionen in diesem modul sichtbar sind, dann sind die chancen optimal für gute compilerarbeit

SideWinder

volkard schrieb:

SideWinder schrieb:

Wenn es wirklcih eine ganze Menge weiterer Aufrufe sind, schau, dass alle Funktionen die selbe Anzahl an Parametern haben.
Dann kannst du mit einem Array von Funktionspointern arbeiten und bin schneller als die Feuerwehr:

switch ist schneller als dein array.
bei switch sollte man natürlich darauf achten, daß die IDs bei 0 beginnen und fortlaufend sind, damit's von dem gleichen vortiele-tellerchen essen kann. außerdem tut ein default: __assume(false); auch ganz gut, wenn man sich's leisten kann (entspricht ungefähr dem assert(ID>=0 && ID<=MAXID)).
switch ist deswegen schneller, weils die kleinen funktionsaufrufe auch inline läßt und hier kann der optimierer zuschlagen.

Oh, switch ist noch besser als ich dachte. Gut zu wissen, danke.

MfG SideWinder

Fein, dann lag ich doch nicht so falsch. Hatte nur befürchtet, dass switch linear abgearbeitet wird, was alles andere als gut gewesen wäre.
Ich bedanke mich für die schnellen Antworten.

PS: Ich habe euren "Feldzug" gegen die Ungarische Notation mitverfolgt und finde das ehrlich gesagt etwas überzogen. Ich benutze Teile der UN weil sie mir hilft (c=Counter, f=Flag usw.) und nicht weil ich sie schön/cool/individuell oder sowas finde. In diesem Beispiel habe ich nichtmal reine UN verwendet sondern nur eine Markierung p für Parameter (im Gegensatz zu m für Member).

THX 1138

MarcoAtWork schrieb:

PS: Ich habe euren "Feldzug" gegen die Ungarische Notation mitverfolgt und finde das ehrlich gesagt etwas überzogen. Ich benutze Teile der UN weil sie mir hilft (c=Counter, f=Flag usw.) und nicht weil ich sie schön/cool/individuell oder sowas finde. In diesem Beispiel habe ich nichtmal reine UN verwendet sondern nur eine Markierung p für Parameter (im Gegensatz zu m für Member).

...das mit der UN wurde schon x Mal diskutiert. Wenn Du alleine codest, machs wies Dir gefällt, im Team sind Konventionen nützlich.
Was ich eher..naja..sagen wir mal..affig finde, ist die Verknüpfung von Wörtern mit Grossbuchstaben, wie zB SideWinder...

btw: was hast Du denn für Arbeitszeiten

Frag lieber nicht. Unser sog. "Projektmanager" (den ich im übrigen für komplett unfähig halte) hat sich etwas verschätzt, was zur folge hat, dass die Arbeitszeit jetzt nurnoch durch Kaffeekochen und kurze Schlafphase unterbrochen werden.
Ich sag euch, traut nie einem Wirtschaftler, der euch sagen will wann was fertig zu sein hat. (Einer meiner Professoren sagte damals: "Solche Leute sind bei Programmierern sehr beliebt und machen hin und wieder auch mal Bekannstschaft mit einem uns wohlbekannten Sportgerät" ermeinte einen Baseballschläger...)

naja...

THX 1138

"Projektmanagement"
"Deadline"

Mein Beileid.
Aber lass Dir wenigstens die Überstunden ordentlich vergolden beim nächsten "Qualifikationsgespräch" ( Bingo ) sprich Lohnverhandlung

@1310-Logik
Wörter die über Großbuchstaben verbunden sind (lies Camel-Notation) sind für den Mensch leichter erfassbar bzw. zu lesen, als Wörter die mit Underscores verbunden sind. Der Unterschied hier ist nicht sehr groß, bevor hier jetzt einer behauptet er hätte keine Probleme sowas zu lesen. Aber er ist da.

Ein gewaltiger Unterschied ist es aber, wenn Wörter komplett in Großbuchstaben geschrieben sind (Die Microsoft-Leute machen das ja fürs Leben gern), dann ist es sehr schwer die einzelne Wörter rauszulesen und es erfordert sehr viel mehr Konzentration, als bei den anderen beiden Varianten.

THX 1138

JederSollteSelbstEntscheidenWasErBesserLesenKannUndDasDannAuchSoAnwenden

jeder_sollte_selbst_entscheiden_was_er_besser_lesen_kann_und_das_dann_auch_so_anwenden

Ich mach übrigens beides: Für Klassen, Typenames/defs, Structs, also alles was einem Typ irgendwie ähnelt, schreib ich erste Version.
Instanzierungen, Variablen etc schreib ich nach zweiter Art.
Dann kann ich das schön trennen.

MeineTolleKlasse eine_tolle_klasse = 0;

jdeer sltole sebslt ehnteidscen was er bseesr leesn knan und das dnan acuh so aeenwdnn

otze

PS: Ich habe euren "Feldzug" gegen die Ungarische Notation mitverfolgt und finde das ehrlich gesagt etwas überzogen. Ich benutze Teile der UN weil sie mir hilft (c=Counter, f=Flag usw.) und nicht weil ich sie schön/cool/individuell oder sowas finde. In diesem Beispiel habe ich nichtmal reine UN verwendet sondern nur eine Markierung p für Parameter (im Gegensatz zu m für Member).

das is ja auch die richtige nutzung der UN gegen die wohl niemand etwas hat. Es geht hier eher um sowas wie iFlag(i=int). Also typinformationen die nie jemand braucht. Was die UN ursprünglich machen wollte, war informationen über den verwendungszweck zu vermitteln, und das ist ok.

volkard

otze schrieb:

das is ja auch die richtige nutzung der UN gegen die wohl niemand etwas hat.

naja, ist auch unfug. kräftig ist sie zum beispiel bei koordinaten kann man horizontale werte mit h und vertikale werte mit v kennzeichnen und wenn da dann steht ha=hk+hp*(hx-hy)/(vm-vb), dann sieht man auf den ersten blick, daß die typengeschichichte stimmt. differenzen und summen haben gleichtypige summanden und so.