LOOP AT
Beitrag
von DeathAndPain (Top Expert / 1952 / 259 /
413
)
»
Du meinst Spectre/Meltdown? Die werden das irgendwie eingeschränkt haben, aber ich glaube nicht, dass sie es ganz unterbunden haben. Das würde zu viel Leistung kosten, dafür sind das zu essentielle Features moderner CPUs. Ich kann mich erinnern, dass mal jemand bei einem Pentium 100 oder was das war probehalber den L2-Cache abgeschaltet hat, um zu sehen, wieviel die Hauptspeicherperformance ausmacht. Daraufhin hat das Teil performt wie ein 286er! Das war niemals allein auf den Hauptspeicher zurückzuführen, sondern damit, dass das ganze Performancegebäude des Pentium auf die Nutzung dieses Cache ausgelegt war und ohne keinen Sinn mehr gemacht hat.
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
https://www.itconductor.com/blog/monito ... erformance
Wir reden schon über ziemliche Performance Einbussen. Das Feature wird quasi abgeschaltet.
Wir reden schon über ziemliche Performance Einbussen. Das Feature wird quasi abgeschaltet.
X muss ja kein ganzzahliger Wert sein...DeathAndPain hat geschrieben:Langsamer ja. "X-fach langsamer" würde ist gerne einen Nachweis sehen.Ein Feldsymbol ist ein Pointer. Ein Modify ist immer xfach langsamer, da speicher hin und herkorpiert werden muss anstatt gleich auf den Speicherbereich zu schreiben.
Ich glaube wir hatten das Thema früher schon mal. Ich stimme dir zu, dass es für ein einzelnes Programm in den meisten Fällen kaum spürbare Gewinne zu verzeichnen gibt. Habe gerade nochmal einen kleinen Test gemacht: eine ITAB mit 700.000 Zeilen - Struktur MARA. In unserem Testsystem benötigt der Modify ca. 0,6 Sekunden länger. Sollte das Programm nur ein paar mal am Tag laufen, dann interessiert das wohl kaum jemanden. Aber wenn es 1.000 mal und mehr am Tag laufen würde, dann wären es mindestens 600 teure Rechnersekunden inklusive unnötigem Energieverbrauch.Und in wie vielen von diesen Fällen war das Umstellen von Workarea auf Feldsymbol mit einem deutlichen Performanceschub belohnt worden in der Gesamtlaufzeit eines Programms? Ich bin ja nicht grundsätzlich gegen performante Programmierung - aber das Feldsymbol als Heilige Kuh des Loops zu behandeln behagt mir halt auch nicht.
Wenn man also die Gesamtsystemlast berücksichtigt, dann macht es eigentlich immer Sinn sich für die schnellere Variante zu entscheiden, zumal im konkreten Fall (aus meiner Sicht!) kein softwaretechnischer Nachteil entsteht.
Beitrag
von DeathAndPain (Top Expert / 1952 / 259 /
413
)
»
Wenn ein Programm, das 700.000 Zeilen einer internen Tabelle modifiziert, 1.000 mal und mehr am Tag laufen würde, dann würde ich als erstes die Frage stellen, was da abgeht. Wenn das wirklich so ein Riesenkonzern ist, dass sowas gerechtfertigt ist, dann wird man auch in ganz anderer Größenordnung Hardwareleistung haben als Dein "Testsystem". Und dann reden wir am Ende doch nur wieder von ein paar Sekunden, über die man nicht reden muss.Habe gerade nochmal einen kleinen Test gemacht: eine ITAB mit 700.000 Zeilen - Struktur MARA. In unserem Testsystem benötigt der Modify ca. 0,6 Sekunden länger. Sollte das Programm nur ein paar mal am Tag laufen, dann interessiert das wohl kaum jemanden. Aber wenn es 1.000 mal und mehr am Tag laufen würde, dann wären es mindestens 600 teure Rechnersekunden inklusive unnötigem Energieverbrauch.
Da kann man mit anderen Softwareoptimierungen viel mehr bewegen.
That being said bin ich (wie schon an anderer Stelle erwähnt) selbst auf die Feldsymbole umgeschwenkt. <TABELLE> als Workarea für die Tabelle TABELLE ist einfach zu attraktiv, vor allem bei lokaler Nutzung mit Inline-Deklaration im LOOP-Befehl. Aber ich stelle mich nicht hin und behaupte, dass das beim Lesen des Programms besser nachzuvollziehen sei als ein expliziter MODIFY.
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Ich finde es nach wie vor intuitiver - aber das liegt im Auge des Betrachters. Subjektiv wichtiger finde ich, dass es bei einem fehlgeschlagenen READ schön dumpt. Eine Feldleiste ist einfach leer, ein Feldsymbol zeigt ins Leere!DeathAndPain hat geschrieben:Aber ich stelle mich nicht hin und behaupte, dass das beim Lesen des Programms besser nachzuvollziehen sei als ein expliziter MODIFY.
Je lauter ein Einschlag ist, umso eher höre ich ihn.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von DeathAndPain (Top Expert / 1952 / 259 /
413
)
»
Das ausgerechnet aus Deinem Mund?!? Es ist die Pflicht jedes sauberen ABAP-Programmierers, sich von der korrekten Zuweisung eines Feldsymbols zu überzeugen, bevor er es verwendet und es eben nicht einfach dumpen zu lassen! READ TABLE dumpt nicht, ASSIGN dumpt auch nicht (noch nicht mal in Verbindung mit 7.40-Syntax). In beiden Fällen sollte man hinterher tunlichst den SY-SUBRC prüfen. Von daher kein Unterschied.Subjektiv wichtiger finde ich, dass es bei einem fehlgeschlagenen READ schön dumpt. Eine Feldleiste ist einfach leer, ein Feldsymbol zeigt ins Leere!
Dass der ASSIGN niemals dumpt, ist mir übrigens extrem sympathisch, weil man sich auf diese Weise häufig einen sperrigen, die Eleganz versauenden TRY-CATCH-ENDTRY-Block sparen kann. Je nach Kontext kann nach dem ASSIGN sogar einfach ein CHECK SY-SUBRC = 0 kommen, und dann ist die Fehlerbehandlung gut!
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Und du machst auch nie was falsch und vergisst auch nie was, das hatte ich vergessen. NATÜRLICH hat das Programm einen Fehler, wenn es dumpt, DARUM will ich, dass es dumpt, wenn ein so kapitaler Fehler drin ist! *kopfschüttel*DeathAndPain hat geschrieben:Das ausgerechnet aus Deinem Mund?!? Es ist die Pflicht jedes sauberen ABAP-Programmierers, sich von der korrekten Zuweisung eines Feldsymbols zu überzeugen, bevor er es verwendet und es eben nicht einfach dumpen zu lassen!Subjektiv wichtiger finde ich, dass es bei einem fehlgeschlagenen READ schön dumpt. Eine Feldleiste ist einfach leer, ein Feldsymbol zeigt ins Leere!
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Das hat niemand behauptet. Kein Grund, so abfällig persönlich zu werden.ralf.wenzel hat geschrieben:Und du machst auch nie was falsch und vergisst auch nie was, das hatte ich vergessen.
Ein Dump, der aufgrund eines nicht zugewiesenen Feldsymbols erfolgt, ist ein Anfängerfehler. Das sehe ich genauso wie TodUndSchmerz.ralf.wenzel hat geschrieben:NATÜRLICH hat das Programm einen Fehler, wenn es dumpt, DARUM will ich, dass es dumpt, wenn ein so kapitaler Fehler drin ist! *kopfschüttel*
Ralf
Natürlich muss man auch bei einem READ INTO wa eine entsprechende Fehlerabfrage machen (nicht nur bei READ ASSIGNING).
In jedem Fall weiß ich vorher: Entweder, es ist egal, ob der READ was gefunden hat oder nicht oder ich stoppe die Programmausführung kontrolliert.
Den Effekt, den du in Kauf nimmst, Ralf, den nutze ich beim Ansprechen von GUI-Controls. Da gibt es häufig 3 - 6 Exceptions, die in den SAP-Beispielprogrammen immer abgefangen werden mit:
Code: Alles auswählen.
IF sy-subrc <> 0.
MESSAE A...
ENDIF.Durch die Auslassung spare ich 6-8 Zeilen Code. Macht vieles übersichtlicher...
Bei Tabellenzugriffen weiß ich aber in der Regel ob und wie ich reagieren muss.
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Ein Flüchtigkeitsfehler. Ich habe schon Leute mit 25 Jahren Berufserfahrung gesehen, die in einer Anwendung 50 READs haben und das bei einem von ihnen vergessen haben.ewx hat geschrieben:Ein Dump, der aufgrund eines nicht zugewiesenen Feldsymbols erfolgt, ist ein Anfängerfehler. Das sehe ich genauso wie TodUndSchmerz.
Für mich ist das wie ein Gurtwarner. Der warnt mich auch, ob ich den Gurt angelegt habe, obwohl ich WEISS, dass ich ohne Gurt nicht fahren darf. Aber ob du es glaubst oder nicht, ich hab es echt schon vergessen, ihn anzulegen.ewx hat geschrieben:In jedem Fall weiß ich vorher: Entweder, es ist egal, ob der READ was gefunden hat oder nicht oder ich stoppe die Programmausführung kontrolliert.
Und dann ist es mir lieber, das Auto fährt gar nicht erst los.....
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Natürlich passiert das. Gerade, wenn man sich vielleicht sicher ist, wie die Daten aussehen.ralf.wenzel hat geschrieben: Ein Flüchtigkeitsfehler. Ich habe schon Leute mit 25 Jahren Berufserfahrung gesehen, die in einer Anwendung 50 READs haben und das bei einem von ihnen vergessen haben.
Trotzdem ein einfacher/ Anfänger-Fehler.
Die Analogie mit dem Gurt würde ich eher so interpretieren: Wenn du den Gurt nicht angelegt hast und die Feldleiste leer ist, dann fährst du vielleicht unangeschnallt in die falsche Richtung. Aber wenn das Feldsymbol nicht zugewiesen ist, macht das Auto eine Vollbremsung.ralf.wenzel hat geschrieben:Für mich ist das wie ein Gurtwarner. Der warnt mich auch, ob ich den Gurt angelegt habe, obwohl ich WEISS, dass ich ohne Gurt nicht fahren darf. Aber ob du es glaubst oder nicht, ich hab es echt schon vergessen, ihn anzulegen.
Und dann ist es mir lieber, das Auto fährt gar nicht erst los.....
Wahrscheinlich gibt es Situationen, wo das eine besser wäre und Situationen, wo es andersherum weniger Ärger gegeben hätte...
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Fakt ist, dass ein nicht READ, der in die Hose geht, nicht missinterpretiert werden kann. Darum geht es mir. Entweder hab ich den Fall berücksichtigt oder es knallt so laut, dass selbst ich das hören kann.
Ralf
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von DeathAndPain (Top Expert / 1952 / 259 /
413
)
»
Ich hatte ja mal in irgendeinem anderen Thread die Story aus meinen Informix 4/GL-Zeiten zum besten gegeben, in denen manche Kollegen am Anfang ihres Programms erst mal pauschal den (selbsterklärenden) Befehl WHENEVER ERROR CONTINUE geschrieben haben. 
Aber was den Gurtwarner angeht - fürchterliche Einrichtung. Wenn es mich in einem der extrem seltenen Fälle, in denen ich den Gurt tatsächlich vergesse, erwischen sollte, dann ist meine Zeit gekommen, dann sollte das so sein. Wenn ich aber aus irgendeinem Grund nur mal rasch umparken und dafür 50 m weiter fahren möchte, dann wäre ein Gurtwarner, der nicht nur belastend fiept, sondern mich gar nicht erst losfahren lässt, ein echtes Ärgernis. Für sowas müsste ich dann extra eine Blindschnalle zum Einstecken im Handschuhfach mitführen.
Aber was den Gurtwarner angeht - fürchterliche Einrichtung. Wenn es mich in einem der extrem seltenen Fälle, in denen ich den Gurt tatsächlich vergesse, erwischen sollte, dann ist meine Zeit gekommen, dann sollte das so sein. Wenn ich aber aus irgendeinem Grund nur mal rasch umparken und dafür 50 m weiter fahren möchte, dann wäre ein Gurtwarner, der nicht nur belastend fiept, sondern mich gar nicht erst losfahren lässt, ein echtes Ärgernis. Für sowas müsste ich dann extra eine Blindschnalle zum Einstecken im Handschuhfach mitführen.
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
...solltest du hoffen, dass die Polizei dich dabei nicht sieht. Ich kenne wirklich Leute, die dafür schon eine Strafe bezahlt haben. Dann lieber Gurtwarner....DeathAndPain hat geschrieben:Wenn ich aber aus irgendeinem Grund nur mal rasch umparken und dafür 50 m weiter fahren möchte
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Ich wusste gar nicht, dass robuste Programmierung so einfach sein kann...DeathAndPain hat geschrieben:WHENEVER ERROR CONTINUE
Erinnere ich mich aber auch gerade wieder dran, dass es das in COBOL so ähnlich auch gab.
Vergleichbare Themen
1
Antw.
Antw.
1484
Views
Views
Loop Loop & Loop - wie am besten eine Verschachtelung vermeiden?
von Sonne1234 » 05.02.2020 16:29 • Verfasst in ABAP® für Anfänger
von Sonne1234 » 05.02.2020 16:29 • Verfasst in ABAP® für Anfänger
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.