Delphi-Internals: Compilerverhalten bei Case statements

[Kedariodakon]

Zitat:

Zitat von Robert Marquardt

Ein guter Compiler koennte da noch viel interessantere Implementierungen machen.
Beispielsweise die einzelnen Cases umsortieren und eine sortierte Sprungtabelle anlegen, die per binaerer Suche ausgewertet wird.

Macht er doch soweit ich das gelesen hab :gruebel:

Bye

[NicoDE]

Zitat:

Zitat von Lemmy1

Folgender Code beispielsweise würde als Tabelle keinen Sinn machen:

Delphi-Quellcode:

Case SomeValue of
  0 : dosomething;
  1000000: dosomethingelse;
end;

Eine Jump-Tabelle würde wieder Sinn machen, wenn mit Faktoren gearbeitet werden würde. Dürfte aber zuviel verlangt sein, dass der Compiler selbst noch den KGV sucht. Insofern könnte man den Compler unterstützen:

Delphi-Quellcode:

case SomeValue div 1000000 of
  0: dosomething;
  1: dosomethingelse;
end;

...auch wenn das Beispiel gerade sinnfrei ist :)

[Robert Marquardt]

Zitat:

Zitat von Kedariodakon

Macht er doch soweit ich das gelesen hab :gruebel:

Was jim_raynor erwaehnt ist nicht sortieren und binaere Suche.
Zugegebenermassen macht binaere Suche nur bei recht vielen Cases Sinn, die nicht genuegend geschlossene Teillisten enthalten.

[Lemmy1]

Nochmal zwei Nachträge:

1. Eine schöne Optimierung hat übrigens C# wenn man switch (entspricht einem Delphi-Case) über Strings macht.

C# kann sowas komplett über Sprungtabellen lösen und zwar indem es über Hashtables arbeitet. Ziemlich cool (und vorallem auch sinnvoll) :) Leider macht Delphi halt gar keine cases über Strings.

2. Zu der Sache mit dem KGV muss ich erstmal zustimmen...

Delphi-Quellcode:

case x of
  0:
  10000:
  20000:
  30000:
  40000:
  else
end;

liese sich natürlich hervorragend optimieren. Allerdings kann das von einem fähigen Entwickler auch getan werden :) Den Unterschied sehe ich hier eben darin, dass ein fähiger Entwickler eben keine Jumptable selbst machen kann (ausser mit assembler direkt natürlich). Insofern macht die generelle Unterstützung viel Sinn, alles weitere ist Bonus...

3. Zu der Frage, wie man erkennt ob es eine Jumptable wurde oder nicht: Geht wie vorher gesagt eigentlich fast nur über die CPU View Alt+Ctrl+C und dann eben Assemblerkenntnisse.
Laufzeitanalysen müssten das aber auch zu Tage bringen. Ein Case mit 1000 Optionen ist eben dann keinen Fatz langsamer als einer mit 100. Dürfte aber schwierig sein, sowas mit den ganz kleinen Zahlen zu messen...

4. Bin froh, dass das nochmal rausgekramt wurde, dachte schon, sowas interessiert keinen :) Gibts hier irgendwo nen Platz, der für solche Threads da ist?