Performance der neuen 7.40-Syntaxen

Re: Performance der neuen 7.40-Syntaxen

DeathAndPain hat geschrieben:Dein eigener Beispielcode hat doch das Gegenteil bewiesen, ewx.

nein.

DeathAndPain hat geschrieben:Ich habe meine Messergebnisse damit ja gepostet. Der READ TABLE ist das performanteste, was Du machen kannst.

Das stellt ja auch keiner in Frage.
Aber es liegt eben nicht an der Verwendung einer klassenbasierten Ausnahme, dass der "inline read" deutlich langsamer ist.
Denn ansonsten müssten diese Variante ebenso langsam sein: Ist sie aber nicht. Der RAISE macht keinen messbaren Unterschied.

Re: Performance der neuen 7.40-Syntaxen

Du hast Recht: "Nicht messbar" stimmt nicht.
Bei dir scheint der Unterschied massiver zu sein, als bei mir:
Bei mir macht der Raise etwa das doppelte der Laufzeit aus. (1-2 ms zu 3-4 ms).
Jedoch definitiv nicht so lange wie der "inline read" mit 10 - 17 ms.

Re: Performance der neuen 7.40-Syntaxen

Die Tabellendefinition ist ja für alle Zugriffe gleich. Und auch der Zugriff ist identisch, da bei jeder Variante der gleiche Zugriffsschlüssel verwendet wird.

Re: Performance der neuen 7.40-Syntaxen

Bei dir scheint der Unterschied massiver zu sein, als bei mir:
Bei mir macht der Raise etwa das doppelte der Laufzeit aus. (1-2 ms zu 3-4 ms).

Das wäre immer noch rasch mal das Doppelte. Wobei wir bei solchen Zahlenwerten natürlich die Rundung massiv mit drin haben. Vielleicht zeigt er ja schon 1 an, wenn nur 0,1 vergangen sind (übrigens Mikrosekunden und nicht wie von Dir gepostet ms; so erbärmlich performt ABAP denn doch nicht ). Deshalb wäre es gut, wenn Du Dein Programm so umbauen würdest, dass der Tabellenzugriff 1000x ausgeführt wird, damit eine nennenswerte Laufzeit entsteht. Dann geht die Performance des DO 1000 TIMES-Befehls natürlich in die Rechnung mit ein, allerdings als konstanter Faktor, so dass die Messergebnisse durchaus eine Interpretation erlauben. Überdies könnte man den DO 1000 TIMES hinterher noch einmal mit leerem Inhalt messen und seine Dauer von der Dauer der übrigen Messläufe jeweils abziehen.

Die Laufzeitunterschiede werden sich auch aus der verwendeten Hardware ergeben. Vielleicht auch aus dem Release und/oder irgendwelchen Systemparametern. Ich bin auf 7.50, Du noch auf 7.40?

Bei mir macht der Raise etwa das doppelte der Laufzeit aus. (1-2 ms zu 3-4 ms).
Jedoch definitiv nicht so lange wie der "inline read" mit 10 - 17 ms.

Dazu hatte ich weiter oben auch schon was gepostet. Der Inline Read ist nicht nennenswert langsamer als der READ TABLE, es sei denn, es gibt die Tabellenzeile nicht, so dass er in den CATCH läuft. Gerade aus diesem Umstand ergibt sich der Schluss, dass die Performance in der Ausnahmeklasse verschwindet. Ersetzt man die mehrfach untervererbte Ausnahmeklasse CX_SY_ITAB_LINE_NOT_FOUND durch eine Primitivklasse, wie Du es in FORM a2 tust, dann ist die Laufzeit schon ein ganzes Stück besser, obwohl Du in a2 noch den IF auf den SY-SUBRC mitmisst. Lässt man die Klassen ganz weg, dann steigt die Performance nochmals um eine ganze Größenordnung an.

Richtig, aber es könnte sein, dass die 7.40-Variante ohne Schlüssel weniger effizient ist. Bei deinem Coding ist das egal, sortierte Tabelle mit Schlüssel....

Das wäre aber mies von der SAP gecodet, wenn der READ TABLE ohne Schlüssel nennenswert schneller sucht als der Inline Read ohne Schlüssel. Und wenn das so sein sollte, dann könnte es genauso sein, dass der READ TABLE mit Schlüssel schneller sucht als der Inline Read. Tatsächlich habe ich den READ TABLE in meinen Messungen (wie eingangs gepostet) ja auch reproduzierbar vorne, freilich nur mit so geringen Geschwindigkeitsunterschieden, dass man es in der Praxis vernachlässigen kann. Gravierend werden die Performanceunterschiede erst dann, wenn die Zeile nicht gefunden wird, weil das den READ TABLE kaum juckt, während jede Form von Coding, das auf eine Ausnahme setzt, dann um ein Vielfaches langsamer performt.

Interessant finde ich aber auch das Detail, dass der LINE_EXISTS unerreicht schnell ist und den READ TABLE TRANSPORTING NO FIELDS deutlich abhängt (jedenfalls wenn man bei letzerem noch den erforderlichen nachfolgenden IF SY-SUBRC <> 0 mitmisst. Vermutlich wird dem READ TABLE hier zum Verhängnis, dass er die ganzen Systemfelder setzen muss, was der LINE_EXISTS sich sparen kann. Außerdem natürlich, dass man keinen separaten IF-Befehl braucht, sondern LINE_EXISTS direkt als boolesches Argument verwenden kann.

An dieser Stelle weine ich einmal mehr meinem C64 hinterher. Dessen Basic konnte jeden numerischen Wert auch boolesch interpretieren mit der einfachen Regel 0 = false, alles andere = true. Statt IF SY-SUBRC <> 0 hätte man da also einfach IF SY-SUBRC gecodet (wenn man mal davon absieht, dass der C64 die Variable SY-SUBRC natürlich nicht gekannt hat, aber in vergleichbare Programmierfälle ist man da auch oft genug reingelaufen).

Zugleich waren mathematische Ausdrücke im IF erlaubt. Da konnte man sich seine booleschen Werte oft mit raffiniert-eleganten Formeln berechnen und brauchte auch nicht mit separaten Bool-Datentypen rumhantieren, die IMHO keine Punkte bringen, auch nicht in der Lesbarkeit, jedenfalls nicht für einen halbwegs kompetenten Programmierer.

Und schließlich hat das auch andersrum funktioniert: ein wahrer boolescher Ausdruck wurde immer zu -1 ausgewertet. Man konnte also schreiben: A = A - ( B = 3) Damit wurde A immer dann um 1 erhöht, wenn B 3 war. Finde ich völlig nützlich und elegant und zugleich nicht so abstrakt, dass man solch Code nicht lesen könnte, wenn man weiß, wie das funktioniert. Das sollten sie auch in ABAP machen!