Laden...

switch - else if

Erstellt von Scheddy vor 17 Jahren Letzter Beitrag vor 17 Jahren 2.381 Views
S
Scheddy Themenstarter:in
58 Beiträge seit 2005
vor 17 Jahren
switch - else if

Hallo,

die Frage ist zwar etwas suspekt, aber trotzdem schwirrt diese mir schon die ganze Zeit im Kopf herrum.

Wieviel schneller ist eine Switchanweisung gegenüber einer if,else if,else if... Abfrage?
Oder gibt es gar keinen Geschwindigkeitsunterschied?

Gruß
Scheddy

S
8.746 Beiträge seit 2005
vor 17 Jahren

Du wirst keine signifikanten Unterschied feststellen können. Der Grund warum man switch einsetzt besteht primär in der Übersichtlichkeit des Codes.

B
249 Beiträge seit 2005
vor 17 Jahren

Und natürlich der Möglichkeit die breaks; wegzulassen umd mehrere Ifs zusammenzufassen 😉

564 Beiträge seit 2005
vor 17 Jahren

Ich hab mal gehört, dass man switch nur bei Zahlen und nicht bei Strings verwenden soll. ka ob da was dran ist.

S
8.746 Beiträge seit 2005
vor 17 Jahren

Strings gehen auch.

5.941 Beiträge seit 2005
vor 17 Jahren

Hallo zusammen

Original von svenson
Strings gehen auch.

Ich glaube Zimd meinte damit die Performance, die bei einer Stringauswertung natürlich niedriger ist.

Gruss Peter

--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011

49.485 Beiträge seit 2005
vor 17 Jahren

Hallo Scheddy,

eine switch-Anweisung kann schneller sein, weil bei if-else alle Abfragen hintereinander ausgeführt werden müssen und beim switch mit einer Operation direkt der richtige case angesprungen werden könnte. Aber die Performance wird und sollte bei der Wahl keine Rolle spielen, sondern ausschließlich die Lesbarkeit.

herbivore

B
1.529 Beiträge seit 2006
vor 17 Jahren

Der Hauptunterschied zwischen switch und if-else besteht darin, dass bei switch die Auswertung einmalig am Anfang des Blockes erfolgt, während bei if-else jeder Zweig erneut die Bedingung prüft.
Dies ist deshalb möglich, weil switch ausschließlich auf eine statische Bedingung prüft, if-else jedoch auch auf dynamische.
Bei einem statischen string-Vergleich benötigen beide damit (bis auf ein paar Takte durch unterschiedliche Maschinenkommandos) die gleiche Ausführungszeit. Wird einer der Vergleichswerte hingegen durch Aufruf einer Methode bestimmt, so ist die statische if-else Verzweigung langsamer, da die Methode mehrfach aufgerufen wird.
Der größte Unterschied zeigt sich jedoch beim Vergleich von ints: bei switch wird nicht nur auf gleich geprüft, sondern vom Compiler ebenfalls größer/kleiner Vergleiche herangezogen (automatische Optimierung, auch im Debug-Modus). Bei einem switch mit aufeinander folgenden ints wird vom Compiler sogar eine Tabelle mit den Adressen der einzelnen cases angelegt und das case über diese Tabelle angesprungen (relative Adressierung).

Zusammenfassung:
Bei statischen, mehrfachen Vergleichen ist ein switch-Statement besser optimierbar und sollte daher den Vorzug erhalten.
Bei einfachen if-else Vergleichen besteht kein signifikanter Unterschied.
Genau aus den oben angeführten Gründen muss für dynamische Vergleiche auch ein if-else-Statement benutzt werden.

Dieses Verhalten kann man sowohl im IL als auch im Maschinencode nachvollziehen.

T
512 Beiträge seit 2006
vor 17 Jahren

Wenn man Zahlen vergleicht wird IMMER alles ausgewertet. Also es wird mit einem einzigen CPU Befehl auf ==, > und < geprüft. Egal ob man das mit nem if oder nem switch macht. Ich glaube man kann mit nem XOR einen Takt sparen, wenn man nur auf Gleichheit prüfen will. Bin mir da aber nicht völlig sicher, und schon garnicht, ob der JITer das auch macht.

Es stimmt, dass switch deutlich besser optimiert werden kann. Zum einen kann man eben eine Jumptable anlegen wenn die Werte dicht beieinander liegen, zum anderen kann man die Werte clever anordnen und eine binäre Suche durchführen, die als C# Code extrem hässlich und unübersichtlich wäre.

Am Ende spielt aber wie herbivore richtig sagte nur die Lesbarkeit eine Rolle. Wenn man das .NET Framework benutzt, ist man schon so weit von der Hardware weg, dass Performancebedenken dieser Art eher sinnlos sind. Faktoren, die man in .NET nur sehr schwer beeinflussen und überschauen kann, wie Caching und Pipelining können einen mit etwas Pech die Abschätzung völlig zunichte machen. Mal davon völlig abgesehen, dass man nahezu nie einen spürbaren Unterschied feststellen wird, selbst wenn alles günstig laufen sollte.

e.f.q.

Aus Falschem folgt Beliebiges

S
Scheddy Themenstarter:in
58 Beiträge seit 2005
vor 17 Jahren

Vielen Dank für die Antworten :>

Jetzt weiß ich bescheid^^