Loop Geschwindigkeit erhöhen
13 Beiträge
•
Seite 1 von 1
13 Beiträge
Seite 1 von 1
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Wenn der LOOP mit z.B. WHERE eine Einschränkung hat, könnte man diese mit einem (Sekundär-)Schlüssel beschleunigen. Alternativ lassen sich auch mit dem "neuen" GROUP BY auch die nachfolgenden READ TABLE reduzieren, wenn man so mehrere gleiche Aufrufe bündeln kann. "Doppelte Zeilen" (sofern man sie haben möchte) lassen sich damit sehr elegant gemeinsam verarbeiten. Last but not least lässt sich auch der READ TABLE mit einem Schlüsselzugriff (hashed oder sorted table) oder BINARY SEARCH (vorsortierte standard table) noch optimieren.
Was meines Erachtens auch noch hilft, ist mit ASSIGNING oder REFERENCE anstatt einer Workarea zu arbeiten. Aber da gibt es unterschiedliche Meinungen und divergierende Laufzeitmessungen.
Was man auf keinen Fall machen sollte, ist innerhalb eines (großen) LOOP mit SELECT (SINGLE) Daten von der Datenbank nachzulesen.
Was meines Erachtens auch noch hilft, ist mit ASSIGNING oder REFERENCE anstatt einer Workarea zu arbeiten. Aber da gibt es unterschiedliche Meinungen und divergierende Laufzeitmessungen.
Was man auf keinen Fall machen sollte, ist innerhalb eines (großen) LOOP mit SELECT (SINGLE) Daten von der Datenbank nachzulesen.
Zuletzt geändert von a-dead-trousers am 11.11.2022 07:54, insgesamt 1-mal geändert.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
a-dead-trousers hat geschrieben: ↑11.11.2022 07:48Wenn der LOOP mit z.B. WHERE eine Einschränkung hat, könnte man diese mit einem (Sekundär-)Schlüssel beschleunigen. Alternativ lassen sich auch mit dem "neuen" GROUP BY auch die nachfolgenden READ TABLE reduzieren, wenn man so mehrere gleiche Aufrufe bündeln kann. Last but not least lässt sich auch der READ TABLE mit einem Schlüsselzugriff (hashed oder sorted table) oder BINARY SEARCH (vorsortierte standard table) noch optimieren.
Was man auf keinen Fall machen sollte, ist innerhalb eines (großen) LOOP mit SELECT (SINGLE) Daten von der Datenbank nachzulesen.
Danke!
Es müssen aber alle Zeilen geändert werden, wenn in den read table passende Einträge existieren.. da komme ich mit einem GROUP BY nicht weiter.
Alle TABELLEN womit ich mit read table lese, sind sortiere Tabellen mit non-unique Key
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Auch mit GROUP BY kann man alle Zeilen ändern. Es geht darum den Zugriff auf die Subtabelle(n) zu optimeren. Sprich wenn z.B. 10 Zeilen in der Haupttabelle existieren, die mit dem selben Schlüssel in der Subtabelle vorkommen, muss man so nur einmal auf diese zugreifen. Die zehn Zeilen der Haupttabelle werden im inneren LOOP AT GROUP mit demselben Ergebnis aus der Abfrage der Subtabelle befüllt.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Hat man nicht eine verschachelte LOOP mit LOOP AT GROUP im inneren eines LOOPs?a-dead-trousers hat geschrieben: ↑11.11.2022 07:58Auch mit GROUP BY kann man alle Zeilen ändern. Es geht darum den Zugriff auf die Subtabelle(n) zu optimeren. Sprich wenn z.B. 10 Zeilen in der Haupttabelle existieren, die mit dem selben Schlüssel in der Subtabelle vorkommen, muss man so nur einmal auf diese zugreifen. Die zehn Zeilen der Haupttabelle werden im inneren LOOP AT GROUP mit demselben Ergebnis aus der Abfrage der Subtabelle befüllt.
Ist dann READ TABLE nicht besser?
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Es schaut ungefähr so aus:
Nicht nur, dass READ TABLE nur für die einmalig vorkommenden Werte in lt_table aufgerufen wird, es werden auch nur die tatsächlich betreffenden Zeilen in lt_table durchlaufen, wenn ein Wert in lt_subtable gefunden wurde.
Ob es jetzt natürlich "schneller" als ein direkter READ TABLE für jede Zeile ist, hängt dann noch von anderen Faktoren ab:
- Wieviele Zeilen hat die Haupttabelle?
- Wieviele "Gruppen" können gebildet werden und wie unfangreich sind diese?
- Wie gut ist GROUP BY im Kernel optimiert? vs. Wie gut ist READ TABLE bei einer sortierten Tabelle optimiert?
Augendscheinlich scheint mir die Lösung mit LOOP und GROUP BY aber doch etwas schneller zu sein, weil "unnötige Pfade" im Code vermieden werden.
Code: Alles auswählen.
LOOP AT lt_table ASSIGNING FIELD-SYMBOL(<ls_line>)
GROUP BY ( field = <ls_line>-field ) ASSIGNING FIELD-SYMBOL(<ls_line_group>).
READ TABLE lt_subtable ASSIGNING FIELD-SYMBOL(<ls_subline>)
WITH KEY field = <ls_line_group>-field.
IF sy-subrc EQ 0.
LOOP AT GROUP <ls_line_group> ASSIGNING FIELD-SYMBOL(<ls_line_member>)
<ls_line_member>-data = <ls_subline>-data.
ENDLOOP.
ENDIF.
ENDLOOP. Ob es jetzt natürlich "schneller" als ein direkter READ TABLE für jede Zeile ist, hängt dann noch von anderen Faktoren ab:
- Wieviele Zeilen hat die Haupttabelle?
- Wieviele "Gruppen" können gebildet werden und wie unfangreich sind diese?
- Wie gut ist GROUP BY im Kernel optimiert? vs. Wie gut ist READ TABLE bei einer sortierten Tabelle optimiert?
Augendscheinlich scheint mir die Lösung mit LOOP und GROUP BY aber doch etwas schneller zu sein, weil "unnötige Pfade" im Code vermieden werden.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
ggfs auch die Verwendung von MODIFY WHERE prüfen.
Folgende Benutzer bedankten sich beim Autor ewx für den Beitrag:
a-dead-trousers
Danke.
In einem Loop muss man ja des öfteren Daten ändern bzw einfügen.
Über Feldsymbole hat man zwar einen Performancevorteil, aber
wenn man Funktionsbausteine verwenden muss, um gewisse Daten zu bekommen, verschlechtert sich doch die Performance? Wie soll man da weitermachen?
In einem Loop muss man ja des öfteren Daten ändern bzw einfügen.
Über Feldsymbole hat man zwar einen Performancevorteil, aber
wenn man Funktionsbausteine verwenden muss, um gewisse Daten zu bekommen, verschlechtert sich doch die Performance? Wie soll man da weitermachen?
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Wenn die Daten von der DB oder anderen "langsamen" Quellen stammen und man das von (Standard-)Funktionsbausteinen nicht besser geregelt bekommt, hilft nur alles selber (vor-)selektieren und dann im Loop nur mehr mit READ TABLE nachlesen (auf keinen Fall SELECT SINGLE).
Alternativ, wenn alles von der DB kommt, kann man sich auch mit einem entsprechend umfangreichen SELECT-Statement oder (CDS-)View die Daten direkt, so wie man sie braucht, in einem Rutsch holen. Dann muss man sich erst gar nicht mit einem (inperformanten) LOOP herumschlagen.
Alternativ, wenn alles von der DB kommt, kann man sich auch mit einem entsprechend umfangreichen SELECT-Statement oder (CDS-)View die Daten direkt, so wie man sie braucht, in einem Rutsch holen. Dann muss man sich erst gar nicht mit einem (inperformanten) LOOP herumschlagen.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
a-dead-trousers hat geschrieben: ↑12.11.2022 12:37Wenn die Daten von der DB oder anderen "langsamen" Quellen stammen und man das von (Standard-)Funktionsbausteinen nicht besser geregelt bekommt, hilft nur alles selber (vor-)selektieren und dann im Loop nur mehr mit READ TABLE nachlesen (auf keinen Fall SELECT SINGLE).
Alternativ, wenn alles von der DB kommt, kann man sich auch mit einem entsprechend umfangreichen SELECT-Statement oder (CDS-)View die Daten direkt, so wie man sie braucht, in einem Rutsch holen. Dann muss man sich erst gar nicht mit einem (inperformanten) LOOP herumschlagen.
Danke!
Ja SELECT habe ich, dank dieses Forums, in einem LOOP sowieso abgewöhnt außer es ist eine kleine Tabelle.
1. Ist der VALUE - FOR Operator schneller als ein READ TABLE? oder macht es kein Unterschied?
2. Sind CDS Views performanter als ABAP SQL?
3. Wenn es geht, immer HASHED oder SORTED Table verwenden, da der Zugriff mit READ TABLE schneller ist? Muss dabei sorted table UNIQUE besitzen für einen besseren Zugriff?
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
1. VALUE FOR ist eher mit einem LOOP zu vergleichen als einem READ TABLE
2. Jein. ABAP SQL wird in die SQL Syntax der Datenbank übersetzt genauso wie das SQL von CDS. Welches jetzt "besser" auf der Datenbank perfomed kann man so nicht pauschal beantworten. Was bei CDS Views aber besser ist, ist der etwas größere Befehlsumfang. Man kann damit um einiges mehr machen als in klassischen ABAP DDIC Views und etwas mehr als in einem ABAP Select-Statement.
3. Auch hier Jein. Wenn sich die Tabelle im Programmlauf des öfteren verändert, kann die Verwendung von sorted oder hashed sogar etwas Performance kosten, weil die Einfügeoperationen dadurch langsamer werden. Ich persönlich verwende lieber standard tables und wenn ich doch mal einen schnellen Zugriff brauche, behelfe ich mir mit einem (wohldosierten) SORT und dann BINARY SEARCH.
Das UNIQUE hat eigentlich keine Auswirkung auf die Performance. Es gibt nur an ob Schlüsselwerte mehrfach vorkommen dürfen oder nicht.
2. Jein. ABAP SQL wird in die SQL Syntax der Datenbank übersetzt genauso wie das SQL von CDS. Welches jetzt "besser" auf der Datenbank perfomed kann man so nicht pauschal beantworten. Was bei CDS Views aber besser ist, ist der etwas größere Befehlsumfang. Man kann damit um einiges mehr machen als in klassischen ABAP DDIC Views und etwas mehr als in einem ABAP Select-Statement.
3. Auch hier Jein. Wenn sich die Tabelle im Programmlauf des öfteren verändert, kann die Verwendung von sorted oder hashed sogar etwas Performance kosten, weil die Einfügeoperationen dadurch langsamer werden. Ich persönlich verwende lieber standard tables und wenn ich doch mal einen schnellen Zugriff brauche, behelfe ich mir mit einem (wohldosierten) SORT und dann BINARY SEARCH.
Das UNIQUE hat eigentlich keine Auswirkung auf die Performance. Es gibt nur an ob Schlüsselwerte mehrfach vorkommen dürfen oder nicht.
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
ZF_SAPler
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Danke, ist der VALUE Operator effizienter?a-dead-trousers hat geschrieben: ↑12.11.2022 16:011. VALUE FOR ist eher mit einem LOOP zu vergleichen als einem READ TABLE
2. Jein. ABAP SQL wird in die SQL Syntax der Datenbank übersetzt genauso wie das SQL von CDS. Welches jetzt "besser" auf der Datenbank perfomed kann man so nicht pauschal beantworten. Was bei CDS Views aber besser ist, ist der etwas größere Befehlsumfang. Man kann damit um einiges mehr machen als in klassischen ABAP DDIC Views und etwas mehr als in einem ABAP Select-Statement.
3. Auch hier Jein. Wenn sich die Tabelle im Programmlauf des öfteren verändert, kann die Verwendung von sorted oder hashed sogar etwas Performance kosten, weil die Einfügeoperationen dadurch langsamer werden. Ich persönlich verwende lieber standard tables und wenn ich doch mal einen schnellen Zugriff brauche, behelfe ich mir mit einem (wohldosierten) SORT und dann BINARY SEARCH.
Das UNIQUE hat eigentlich keine Auswirkung auf die Performance. Es gibt nur an ob Schlüsselwerte mehrfach vorkommen dürfen oder nicht.
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Wenn es darum geht, Werte aus einer Tabelle in eine andere (mit anderer Struktur und eventuellen Konvertierungen) zu kopieren, würde ich mal sagen, ja. Weil es damit nur einen Befehl braucht.
Wenn es darum geht mehrere, gleiche Werte in einer Tabelle zu ergänzen, würde ich MODIFY verwenden.
Wenn es darum geht, mehrere unterschiedliche Werte in einer Tabelle zu ergänzen, würde ich LOOP AT verwenden.
Etwas OT:
Die Effizienz ergibt sich immer aus der Anwendung heraus und kann eigentlich in keiner Programmiersprache für an sich ähnliche Befehle pauschal beantwortet werden.
ABAP ist ja nur deshalb so "geschwätzig" geworden, weil man eben versucht hat für bestimmte, wiederkehrende Abläufe, effizientere Befehle zu schaffen. Das heißt nicht, dass die alten Befehle "schlechter" sind, nur dass sie eben nicht mehr weiter verbesserte werden konnten, ohne das man andere Abläufe wieder verschlechtert hätte.
Ein gutes Beispiel dafür sind die Versuche von Google, Mozilla und Co. ihre JavaScript Implementierungen zu beschleunigen, indem man versucht mit "predictive" Analysen das Verhalten des Codes vorauszusehen und dann wiederkehrende, teure Operationen durch kompilierten Maschinencode zu ersetzen, anstatt sie immer wieder durch den Interpreter zu jagen. Das ist genau der gegenteilige Ansatz zu dem was die SAP verfolgt. Damit eben die Sprache nicht zu geschwätzig wird, versucht man "unter der Haube" zu verbessern, mit unterschiedlichen positiven oder negativen Auswüchsen. In "künstlichen" Performancetest mögen solche Ansätz enorme Geschwindigkeitsvorteile bieten, nur scheitert so ein Vorgehen meist an realen, allerwelts Problemen, wenn der Programmierer diese Vorteile nicht kennt oder sie nicht korrekt einzusetzen vermag. Da muss man eben die bestehenden Befehle und Abläufe so "umordnen", dass der Compiler/Interpreter das Optimierungspotenzial erkennen kann. Natürlich auch mit eventueller "Verschlechterung" von bereits bestehendem Coding. Der SAP Ansatz sieht dafür eben gleich neue Befehlskonstrukte vor, anstatt den "alten" Befehlen neue Bedeutungen zukommen zu lassen oder diese schlimmsten Falls sogar zu verschlechtern.
Wenn es darum geht mehrere, gleiche Werte in einer Tabelle zu ergänzen, würde ich MODIFY verwenden.
Wenn es darum geht, mehrere unterschiedliche Werte in einer Tabelle zu ergänzen, würde ich LOOP AT verwenden.
Etwas OT:
Die Effizienz ergibt sich immer aus der Anwendung heraus und kann eigentlich in keiner Programmiersprache für an sich ähnliche Befehle pauschal beantwortet werden.
ABAP ist ja nur deshalb so "geschwätzig" geworden, weil man eben versucht hat für bestimmte, wiederkehrende Abläufe, effizientere Befehle zu schaffen. Das heißt nicht, dass die alten Befehle "schlechter" sind, nur dass sie eben nicht mehr weiter verbesserte werden konnten, ohne das man andere Abläufe wieder verschlechtert hätte.
Ein gutes Beispiel dafür sind die Versuche von Google, Mozilla und Co. ihre JavaScript Implementierungen zu beschleunigen, indem man versucht mit "predictive" Analysen das Verhalten des Codes vorauszusehen und dann wiederkehrende, teure Operationen durch kompilierten Maschinencode zu ersetzen, anstatt sie immer wieder durch den Interpreter zu jagen. Das ist genau der gegenteilige Ansatz zu dem was die SAP verfolgt. Damit eben die Sprache nicht zu geschwätzig wird, versucht man "unter der Haube" zu verbessern, mit unterschiedlichen positiven oder negativen Auswüchsen. In "künstlichen" Performancetest mögen solche Ansätz enorme Geschwindigkeitsvorteile bieten, nur scheitert so ein Vorgehen meist an realen, allerwelts Problemen, wenn der Programmierer diese Vorteile nicht kennt oder sie nicht korrekt einzusetzen vermag. Da muss man eben die bestehenden Befehle und Abläufe so "umordnen", dass der Compiler/Interpreter das Optimierungspotenzial erkennen kann. Natürlich auch mit eventueller "Verschlechterung" von bereits bestehendem Coding. Der SAP Ansatz sieht dafür eben gleich neue Befehlskonstrukte vor, anstatt den "alten" Befehlen neue Bedeutungen zukommen zu lassen oder diese schlimmsten Falls sogar zu verschlechtern.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Seite 1 von 1
Vergleichbare Themen
35
Antw.
Antw.
4763
Views
Views
5
Antw.
Antw.
1355
Views
Views
Geschwindigkeit Optimieren bei Loop und Zuweisung
von autohandel7 » 15.01.2019 10:24 • Verfasst in ABAP® für Anfänger
von autohandel7 » 15.01.2019 10:24 • Verfasst in ABAP® für Anfänger
1
Antw.
Antw.
1444
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
4
Antw.
Antw.
6864
Views
Views
1
Antw.
Antw.
1944
Views
Views
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.