LOOP AT

Re: LOOP AT

ralf.wenzel hat geschrieben: Das Feldsymbol bringt was - aber wohl eher bei großen Tabellen.

ich hab das mit dem Feldsymbolen wegen den Modifikationen erwähnt
ich hab es lieber, als ein Modify in einem Loop.

Grüße 4byte

Re: LOOP AT

Ich dagegen sehe lieber den ausdrücklichen MODIFY.
Der MOVE in irgendein Feldsymbol zeigt mir nicht sofort
an daß die Tabelle modifiziert wird - der MODIFY schon.
(Wir reden nicht von Hello-World-Programmen).

Re: LOOP AT

ralf.wenzel hat geschrieben:Nein, in einer Standardtabelle geht ein LOOP AT WHERE nicht schneller als ein LOOP AT, weil alle Sätze sequentiell durchlaufen werden

Ganz so ist es nicht, denn ohne WHERE braucht man immer noch zusätzliche Befehle (etwa einen CHECK-Befehl, der die unerwünschten Zeilen verwirft). Ein LOOP WHERE mag auf einer Standardtabelle auch sequentiell suchen, führt mit den unerwünschten Zeilen aber zumindest keine weiteren Befehle aus.

ralf.wenzel hat geschrieben:Das Problem dabei ist: Ich schreibe in ein Feld, das ein Tabellenfeld ist (ja, ich weiß, eigentlich ist es in die Workarea kopiert und wird nur dort geändert

Genau letzteres ist aber der Punkt: Du schreibst eben nicht in ein Tabellenfeld, sondern in irgendein anderes Feld. Daraufhin verändert sich automagisch der Tabelleninhalt. Das ist nicht transparent.

Anders sieht es aus, wenn Du einen expliziten Befehl (MODIFY) hast, der sagt, dass der Tabelleninhalt jetzt vermittelst dieses Drittfeldes geändert werden soll.

Dessen ungeachtet bin ich inzwischen auch zu Feldsymbolen übergegangen. Oft braucht man ja nur einen einzigen Loop über die Tabelle (jedenfalls in dem betreffenden Unterprogramm), und da ist die Inline-Deklaration ASSIGNING FIELD-SYMBOL(<tabellenname>) einfach wundervoll. Man bekommt eine Workarea, die performant ist und zugleich ohne den sperrigen WA_-Vorbau auf einen Blick als Workarea dieser Tabelle erkennbar ist. Eine Workarea, die sogar den gleichen Namen wie die Tabelle trägt. Die Feldsymbolwinkel nehme ich dabei als Workarea-Kennzeichner wahr (obwohl ich natürlich um ihre wahre Bedeutung weiß). Das ganze kommt der Lesbarkeit so sehr entgegen, dass ich auf den MODIFY da verzichten kann.

ralf.wenzel hat geschrieben:Zudem bin ich einer der ganz großen MODIFY-Vergesser (gerade im LOOP AT SCREEN, weil ich den MODIFY sonst nie verwende).

Na, dann liegt die Lösung doch auf der Hand: Gewöhn Dir auch sonst den MODIFY an, dann vergisst Du ihn im LOOP AT SCREEN auch nicht mehr.

Re: LOOP AT

ralf.wenzel hat geschrieben:Wenn ich z. B. ein Feld ändern will in einer ITAB,

dann verwende ich einen entsprechend parametrisierten MODIFY.
Der macht das ganz ohne einen überflüssigen LOOP.

Re: LOOP AT

Daniel hat geschrieben:Ich dagegen sehe lieber den ausdrücklichen MODIFY.
Der MOVE in irgendein Feldsymbol zeigt mir nicht sofort
an daß die Tabelle modifiziert wird - der MODIFY schon.
(Wir reden nicht von Hello-World-Programmen).

Er zeigt es Dir nur nicht an, wenn Du das Wesen von Feldsymbolen nicht verstanden hast, sorry.

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.

Bei wirklich großen Tabellen, wäre dein Vorgehen mit Modify extrem sträflich und würde von mir nicht in ein P System gelagen.

Re: LOOP AT

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. Zumal ich gerade erst gelernt habe, dass es durchaus Situationen geben soll, wo ein Feldsymbol langsamer ist als eine Workarea.

Re: LOOP AT

Genaue Situation habe ich mir nicht genauer erläutern lassen. Es ging darum, dass z.B. bei sehr schmalen Tabellen eine Workarea evtl. gut gecacht sein könnte ( L1-Cache des Prozessors ) und dass weiterhin in diesem Fall wohl durch prozessorseitiges Cache-Prefetching und Speculative Execution sich die Faustregel "FS>WA" hier umkehrt. Du siehst - wir sprechen hier schon von sehr besonderen Konstellationen.
Allerdings habe ich absichtlich den Konjunktiv verwendet, da ich ich aktuell keine Lust habe mir das genauer anzuschauen und zu verifizieren und andererseits in den Umfeldern, in denen ich entwickle, die Laufzeitoptimierungen auf ganz anderen Leveln gemacht werden. Und die Entscheidung "FS oder WA" ist in den allerseltensten Fällen das, was am Ende wirklich wichtig ist.

Re: LOOP AT

black_adept hat geschrieben:[...] prozessorseitiges Cache-Prefetching und Speculative Execution [...]

Speculative Execution ist bei hochgepatchten OS in den allermeisten Fällen akutell ohnehin unterbunden... aber das ist ja wieder nochmal ein ganz anderes Thema