Performance-Problem
Beitrag
von black_adept (Top Expert / 4090 / 127 /
940
)
»
Das liegt natürlich voll im Auge des Betrachters. Ich finde das Coding i.O. und nicht veraltet. Und denk dran - wenn du zu neu programmierst bekommst du von einem anderen Teil der Leserschaft einen übergebraten.DeathAndPain hat geschrieben:Ansonsten nochmal die Frage: War euer Systemstand nicht schon auf 7.40? (Herausfinden im SAPGui über Menü System -> Status, Klicken auf Lupe -> Release der Komponente SAP_ABA anschauen. Wenn ja, dann solltest Du Dir unbedingt einen grundlegend anderen Programmierstil angewöhnen. Dann ist Dein Codingstil nämlich als ziemlich veraltet einzuschätzen; das kann man mit den neuen Mitteln von 7.40 alles viel kürzer und schöner programmieren.
Hinweis zum Programm selber ( aber das hat nix mit veraltet zu tun ).
- CASE statt IF-ENDIF-Bedingungen, die jeweils disjunkte Teilmengen abgrenzen.
- Du hast die Variablen gs_output und <gs_output> und verwendest beide. Ich fürchte, dass das nicht so gewollt ist
- gs_output, gs_mdkp sind bestimmt eine globale Variablen - das ist böse und wird hier nicht geduldet.
- <gs_output> könnte lokal definiert werden ( vielleicht ist es ja das was D&P als veralteteten Stil bezeichnet ) und müsste dann natürlich umbenannt werden
- Die ganze CLEAR&REFRESH-Arie am Ende ist völlig überflüssig, da die Variablen doch gar nicht angefasst werden. Innerhalb des Loops erst recht
- best_idx wird nirgendwo gesetzt - du liest immer aus der 1. Zeile
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
cuncon
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Das sind worst-case ja doch immerhin 150mio Durchläufe der inneren Schlaufe. Da kann die Laufzeit ja schonmal länger dauern.
Aber um deine Performance wirklich messen zu können, kannst du das Programm ja mal durch die Transaktion SAT hauen und schauen was dabei raus kommt.
Aber um deine Performance wirklich messen zu können, kannst du das Programm ja mal durch die Transaktion SAT hauen und schauen was dabei raus kommt.
Entschuldigung, dass ich nur ein Teil von meinem Code kopiert habe. Im meinem Code best_idx wird benutzt. Frage zu dem globale gs_output, gs_mdkp: ich habe keine Unterprogramme geschrieben, daher muss ich alle Variable global definieren oder? oder war das ein Denkfehler? Ich habeblack_adept hat geschrieben:Das liegt natürlich voll im Auge des Betrachters. Ich finde das Coding i.O. und nicht veraltet. Und denk dran - wenn du zu neu programmierst bekommst du von einem anderen Teil der Leserschaft einen übergebraten.DeathAndPain hat geschrieben:Ansonsten nochmal die Frage: War euer Systemstand nicht schon auf 7.40? (Herausfinden im SAPGui über Menü System -> Status, Klicken auf Lupe -> Release der Komponente SAP_ABA anschauen. Wenn ja, dann solltest Du Dir unbedingt einen grundlegend anderen Programmierstil angewöhnen. Dann ist Dein Codingstil nämlich als ziemlich veraltet einzuschätzen; das kann man mit den neuen Mitteln von 7.40 alles viel kürzer und schöner programmieren.
Hinweis zum Programm selber ( aber das hat nix mit veraltet zu tun ).
- CASE statt IF-ENDIF-Bedingungen, die jeweils disjunkte Teilmengen abgrenzen.
- Du hast die Variablen gs_output und <gs_output> und verwendest beide. Ich fürchte, dass das nicht so gewollt ist
- gs_output, gs_mdkp sind bestimmt eine globale Variablen - das ist böse und wird hier nicht geduldet.
- <gs_output> könnte lokal definiert werden ( vielleicht ist es ja das was D&P als veralteteten Stil bezeichnet ) und müsste dann natürlich umbenannt werden
- Die ganze CLEAR&REFRESH-Arie am Ende ist völlig überflüssig, da die Variablen doch gar nicht angefasst werden. Innerhalb des Loops erst recht
- best_idx wird nirgendwo gesetzt - du liest immer aus der 1. Zeile
<gs_output> und gs_output benutzt, weil ich mich nicht so gut mit FIELD-Symbol umgehen kann und aber versucht es zu benutzen, weil es schneller ist
.
Beitrag
von black_adept (Top Expert / 4090 / 127 /
940
)
»
ARGH. Das ist ja wie bei Edgar Wallace, wo kurz vor Schluss vorher unbekannte Personen auftauchen, die zur Aufklärung des Falls wichtig sind. Woher weißt du, dass dein Laufzeitfresser nicht in dem Teil drin ist, den du weggelassen hast.cuncon hat geschrieben:...dass ich nur ein Teil von meinem Code kopiert habe....
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag (Insgesamt 2):
Somani • cuncon
Ich habe bei mir gekuckt, wir habe Release 701black_adept hat geschrieben:Das liegt natürlich voll im Auge des Betrachters. Ich finde das Coding i.O. und nicht veraltet. Und denk dran - wenn du zu neu programmierst bekommst du von einem anderen Teil der Leserschaft einen übergebraten.DeathAndPain hat geschrieben:Ansonsten nochmal die Frage: War euer Systemstand nicht schon auf 7.40? (Herausfinden im SAPGui über Menü System -> Status, Klicken auf Lupe -> Release der Komponente SAP_ABA anschauen. Wenn ja, dann solltest Du Dir unbedingt einen grundlegend anderen Programmierstil angewöhnen. Dann ist Dein Codingstil nämlich als ziemlich veraltet einzuschätzen; das kann man mit den neuen Mitteln von 7.40 alles viel kürzer und schöner programmieren.
Hinweis zum Programm selber ( aber das hat nix mit veraltet zu tun ).
- CASE statt IF-ENDIF-Bedingungen, die jeweils disjunkte Teilmengen abgrenzen.
- Du hast die Variablen gs_output und <gs_output> und verwendest beide. Ich fürchte, dass das nicht so gewollt ist
- gs_output, gs_mdkp sind bestimmt eine globale Variablen - das ist böse und wird hier nicht geduldet.
- <gs_output> könnte lokal definiert werden ( vielleicht ist es ja das was D&P als veralteteten Stil bezeichnet ) und müsste dann natürlich umbenannt werden
- Die ganze CLEAR&REFRESH-Arie am Ende ist völlig überflüssig, da die Variablen doch gar nicht angefasst werden. Innerhalb des Loops erst recht
- best_idx wird nirgendwo gesetzt - du liest immer aus der 1. Zeile
black_adept hat geschrieben:ARGH. Das ist ja wie bei Edgar Wallace, wo kurz vor Schluss vorher unbekannte Personen auftauchen, die zur Aufklärung des Falls wichtig sind. Woher weißt du, dass dein Laufzeitfresser nicht in dem Teil drin ist, den du weggelassen hast.cuncon hat geschrieben:...dass ich nur ein Teil von meinem Code kopiert habe....
Ich habe debuggert und auch FUBA 'SAPGUI_PROGRESS_INDICATOR eingebaut, daher konnte ich sehen, bei welcher Matnr das Programm stand. Ich habe folgender Code eingebaut:
Code: Alles auswählen.
LOOP AT gt_bestandliste ASSIGNING <gs_bestandliste> WHERE delb0 = 'W-BEST' OR delb0 = 'KD-BST' OR delb0 = 'K-AUFT' OR delb0 = 'LIEFER' OR delb0 = 'SK-BED'.
CONCATENATE 'Lesen LOOP AT gt_bestandliste bei matnr' <gs_output>-matnr INTO gv_text SEPARATED BY space.
CALL FUNCTION 'SAPGUI_PROGRESS_INDICATOR'
EXPORTING
* PERCENTAGE = 0
TEXT = gv_text.
Zuletzt geändert von cuncon am 27.02.2018 12:48, insgesamt 2-mal geändert.
Beitrag
von DeathAndPain (Top Expert / 1944 / 257 /
413
)
»
Nur ein Beispiel: StattDas liegt natürlich voll im Auge des Betrachters. Ich finde das Coding i.O. und nicht veraltet.
Code: Alles auswählen.
i = best_idx + 1.
READ TABLE gt_bestandliste_temp INDEX i INTO gs_bestandliste_temp.
IF sy-subrc = 0.
IF gs_bestandliste_temp-planr <> <gs_bestandliste>-planr.
<gs_output>-ovflag = 'X'.
ENDIF.
ENDIF.TRY.
IF gt_bestandliste_temp[ best_idx + 1 ]-planr <> <gs_bestandsliste>-planr.
<gs_output>-ovflag = 'X'.
ENDIF.
CATCH cx_sy_itab_line_not_found. " no action required
ENDTRY.
Hier im Forum kann ich meinen Code leider nicht in den code-Tags schreiben, da die bei eckigen Klammern im Code verrückt spielen.
Mit diesem Code sparste Dir die komplette Workarea gs_bestandliste_temp (die kann dann also auch oben aus dem DATA rausfliegen, ein Feld weniger), Du sparst Dir die Hilfsvariable i, die kann dann also auch oben aus dem DATA rausfliegen, Du liest nicht eine komplette Tabellenzeile aus gt_bestandliste_temp, obwohl Du nur das Feld planr daraus brauchst (hätte man beim READ TABLE auch hinkriegen können, indem man einen sperrigen TRANSPORTING planr dahinterschreibt), und zusätzlich zu den entfallenden Datendeklarationen ist der ganze Code auch noch kürzer und besser lesbar. Wenn wir davon ausgehen, dass <gs_output>-ovflag seinem Namen Ehre macht und ein Flag ist, dass andernfalls auf Space stehen soll, dann geht es sogar noch schicker:
TRY.
<gs_output>-ovflag = cond #( WHEN gt_bestandliste_temp[ best_idx + 1 ]-planr <> <gs_bestandsliste>-planr THEN 'X' ).
CATCH cx_sy_itab_line_not_found. " no action required
ENDTRY.
Jetzt mal ehrlich: Diese vier Zeilen gegen seinen ganzen Codeblock plus dafür erforderlche Hilfsvariablen: Das ist doch viel geiler!
Etwas performanter obendrein.Habe ich hier noch nicht erlebt. Diejenigen, die noch Ente fahren, wagen es hier nicht aufzubegehren.Und denk dran - wenn du zu neu programmierst bekommst du von einem anderen Teil der Leserschaft einen übergebraten.
Und es werden ja auch immer weniger. 7.40 ist ja längst kein brandneues Release mehr; wir sind schon lange bei 7.50 (eigentlich sogar bei 7.52, auch wenn das uns ERP 6.0'ern bislang verweigert wird).Aber da cuncon inzwischen geklärt hat, dass er noch 7.01 hat, kann man ihm da wohl keinen Vorwurf machen (wohl aber empfehlen, seine Basis zu beharken
).Aber ja, es gibt auch Schönheitsmängel in seinem Programm, die nichts mit dem Release zu tun haben. Du hast einige aufgezählt, ich würde noch ergänzen:
- Doppelpunkte verwenden, anstatt denselben Befehl (CLEAR) mehrfach hintereinander aufzuzählen
- CASE zu bevorzugen (wo nicht COND/SWITCH geht
) ist richtig, aber auch da, wo IF sinnvoll/notwendig ist, sollte man AND nehmen, anstatt IFs ohne Not ineinander zu schachteln.
Beitrag
von DeathAndPain (Top Expert / 1944 / 257 /
413
)
»
Das kann aber eigentlich nicht sein. Hängenbleiben gibt der Code Deiner inneren Schleife nicht her.bei der 2.Schleife LOOP AT gt_bestandliste ist das Programm bei einer bestimmten Matnr hängen geblieben, also nach 20 Minuten stand das Programm. Sonst läuft ziemlich schnell bei meistens Materialnummer
Da würde ich mal bei der Materialnummer mit dem Debugger einsteigen und schauen, wo und warum er sich im Kreise dreht oder stehenbleibt.
Beitrag
von black_adept (Top Expert / 4090 / 127 /
940
)
»
@D&P:
1.) Die beiden blauen Codeblöcke ergeben nicht immer das selbe Ergebnis ( fehlerhafte Verwendung der COND-Anweisung )
2.) Da nur der erste blaue Codeblock korrekt war: Das sind dann nicht 4 sondern 6 Zeilen. Und mit 6 Zeilen bekommt man das auch "altbacken" hin. ( Allerdings könnte man den 2. blauen Block fixen, damit er doch korrekt wäre - nur dass dann wieder mehr geschrieben werden müsste und evtl. die Laufzeit wegen einer überflüssigen Zuweisung abnähme )
3.) Ich halte den blauen Code nicht für so viel toller als den Originalcode ( obwohl ich wohl selber den blauen schreiben würde )
4.) Nur um es festzuhalten: Es geht auch mit nur einem Befehl. Der braucht dann auch ganz ganz viele neue Sprachelemente
1.) Die beiden blauen Codeblöcke ergeben nicht immer das selbe Ergebnis ( fehlerhafte Verwendung der COND-Anweisung )
2.) Da nur der erste blaue Codeblock korrekt war: Das sind dann nicht 4 sondern 6 Zeilen. Und mit 6 Zeilen bekommt man das auch "altbacken" hin. ( Allerdings könnte man den 2. blauen Block fixen, damit er doch korrekt wäre - nur dass dann wieder mehr geschrieben werden müsste und evtl. die Laufzeit wegen einer überflüssigen Zuweisung abnähme )
3.) Ich halte den blauen Code nicht für so viel toller als den Originalcode ( obwohl ich wohl selber den blauen schreiben würde )
4.) Nur um es festzuhalten: Es geht auch mit nur einem Befehl. Der braucht dann auch ganz ganz viele neue Sprachelemente
Beitrag
von DeathAndPain (Top Expert / 1944 / 257 /
413
)
»
Das bestreite ich. Im Text zum zweiten Codeblock habe ich betont, dass dieser dann eine Alternative darstellt, wenn es sich (dem Namen entsprechend) bei <gs_output>-ovflag um ein Flag handelt, welches ABAP-typisch die Werte 'X' und SPACE annehmen kann. Dafür spricht neben dem Namen des Feldes auch die Tatsache, dass cuncon ihm selber 'X' zuweist. Wenn dann noch sichergestellt ist, dass das Feld SPACE sein soll, wenn der IF nicht hinhaut (und auch das kommt mir bei diesem Coding durchaus wahrscheinlich vor), dann ist mein Coding eine funktionierende Alternative.1.) Die beiden blauen Codeblöcke ergeben nicht immer das selbe Ergebnis ( fehlerhafte Verwendung der COND-Anweisung )
Ich habe also klar im Begleittext erläutert, dass der zweite blaue Block zwar nicht völlig inhaltsäquivalent zum Ursprungscode ist, wahrscheinlich aber auch das gewünschte Ergebnis abliefert - und damit eben doch eine Alternative darstellt.
Allein schon deshalb nicht, weil Du beim Ursprungscode noch außerhalb des zitierten Bereiches zwei weitere Zeilen für die Deklaration der Hilfsvariablen i und gt_bestandliste_temp brauchst.2.) Da nur der erste blaue Codeblock korrekt war: Das sind dann nicht 4 sondern 6 Zeilen. Und mit 6 Zeilen bekommt man das auch "altbacken" hin.
Beitrag
von black_adept (Top Expert / 4090 / 127 /
940
)
»
OK - muss dir recht geben. Aber nur, weil du in dem von dir zitierten Codeschnipsel vergessen hast die VorbedingungDeathAndPain hat geschrieben:Das bestreite ich. Im Text zum zweiten Codeblock habe ich betont, dass dieser dann eine Alternative darstellt, wenn es sich (dem Namen entsprechend) bei <gs_output>-ovflag um ein Flag handelt, welches ABAP-typisch die Werte 'X' und SPACE annehmen kann. Dafür spricht neben dem Namen des Feldes auch die Tatsache, dass cuncon ihm selber 'X' zuweist. Wenn dann noch sichergestellt ist, dass das Feld SPACE sein soll, wenn der IF nicht hinhaut (und auch das kommt mir bei diesem Coding durchaus wahrscheinlich vor), dann ist mein Coding eine funktionierende Alternative.1.) Die beiden blauen Codeblöcke ergeben nicht immer das selbe Ergebnis ( fehlerhafte Verwendung der COND-Anweisung )
Code: Alles auswählen.
IF <gs_output>-ovflag IS INITIAL.
Beitrag
von black_adept (Top Expert / 4090 / 127 /
940
)
»
DeathAndPain hat geschrieben:Jetzt mal ehrlich: Diese vier Zeilen gegen seinen ganzen Codeblock plus dafür erforderlche Hilfsvariablen: Das ist doch viel geiler!
Hilfsvariablen fressen kein Brot und machen Code nicht unleserlich. Und weniger Codezeilen/Anweisungen/Buchstaben oder was auch immer halte ich immer noch nicht für einen Indikator für gutes oder schlechtes Coding. Denn dann wäre der 1-Zeiler ( 1 Befehl ) deinem 4-Zeiler überlegen.DeathAndPain hat geschrieben:Allein schon deshalb nicht, weil Du beim Ursprungscode noch außerhalb des zitierten Bereiches zwei weitere Zeilen für die Deklaration der Hilfsvariablen i und gt_bestandliste_temp brauchst.
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
cuncon
Beitrag
von DeathAndPain (Top Expert / 1944 / 257 /
413
)
»
Würde ich nicht so sehen - bzw. nur bedingt. Edgar Wallace ist das alles insofern, als zumindest mir nicht klar ist, welchem Zweck die ganzen Felder dienen, die in cuncons Code hin- und hergeschoben werden (vielleicht auch deshalb, weil ich mit dem FB und dem SAP-Modul, in dem er da unterwegs ist, nicht vertraut bin). Das kann man nur versuchen, anhand bestimmter Merkmale (wie z.B. dem Feldnamen, der das Wort "Flag" enthält) zu erraten, was beabsichtigt ist.Wieder so ein Edgar Wallace Fall.
Der Code erweckt aber durchaus den Eindruck, dass hier eine Reihe von Werten anhand von anderen Werten ermittelt und dann in der internen Tabelle abgelegt werden soll. <gs_output>-ovflag ist einer davon. Insofern liegt die Vermutung dringend nahe, dass diese Werte nicht vorher schon gesetzt waren, denn sie gehen an keiner Stelle in cuncons Ermittlungscode ein. Nun kannst Du natürlich sagen, vielleicht ist <gs_output>-ovflag ja eine Ausnahme und kann als Flag vorher schon gesetzt sein. Unmöglich ist das nicht, aber naheliegend ist es angesichts der Beschaffenheit von cuncons Code eben auch nicht, weswegen ich gesagt habe, wenn ich mit meiner Vermutung richtig liege, dass das ein Flag ist, dessen Wert an dieser Codestelle neu bestimmt wird, dann geht auch mein zweiter blauer Code. (Ggf. könnte der sogar ein vergessenes CLEAR ersetzen, da er es implizit enthält.)
Insofern Edgar Wallace, dass man erraten muss, was der Zweck von cuncons Code ist, aber nicht Edgar Wallace wegen der von Dir erwähnten Zeile. Die taugt als Beweis, dass mein Code passt, aber selbst wenn sie nicht da wäre, würde ich bei ausschließlicher Betrachtung des von mir exemplarisch herausgegriffenen Codestücks dennoch vermuten, dass er im Sinne dessen, was das Programm tun soll, dennoch passt. Und ich habe ja auch im begleitenden Text darauf hingewiesen, dass dies zu prüfen ist.
Nun kann man natürlich sagen, durch die Verschachtelung der LOOPs ist erkennbar, dass das Feld zu Beginn des von mir herausgegriffenen Codeabschnitts nicht immer initial sein wird. Das stimmt. So weit habe ich mich da nicht reingedacht, als ich mir mehr oder weniger willkürlich ein Codestück als Beispiel herausgegriffen habe, das sich gut zur Optimierung mit 7.40-Befehlen eignen würde.
Beitrag
von DeathAndPain (Top Expert / 1944 / 257 /
413
)
»
Das sehe ich anders. Ich finde es durchaus sprechender, die (in 7.40 gleichfalls erlaubte) SyntaxHilfsvariablen fressen kein Brot und machen Code nicht unleserlich.
Code: Alles auswählen.
READ TABLE ttt INDEX i + 1.Code: Alles auswählen.
DATA temp_i type i.
temp_i = i + 1.
READ TABLE ttt INDEX temp_i.Ich halte es für einen der größten Verdienste der 7.40-Syntax, dass man kaum noch die blöden Workareas braucht. Nicht von ungefähr waren die der Hauptgrund, aus dem ich bisher so ein großer Fan von Kopfzeilen war. Die brauche ich inzwischen kaum noch und habe dennoch nicht die blöden WA_TABELLENNAME-Felder in meinem Code drin.
Davon abgesehen ist der Code ohne die Hilfsvariablen natürlich auch noch etwas schneller. Und ein DATA-Block wird auch nicht unleserlicher, wenn er kürzer wird...
Es ist kein absolut zwingender Zusammenhang, aber in den allermeisten Fällen ist der kürzere Code auch der besser lesbare. Das ist ja auch ein hier gerne ins Feld geführtes Kernargument für Ketten-Methodenaufrufe im Gegensatz zu Funktionsbausteinen. Nur in wenigen Fällen (zu denen insbesondere der zweifelhafte FOR-Befehl zählt) ist es anders.Und weniger Codezeilen/Anweisungen/Buchstaben oder was auch immer halte ich immer noch nicht für einen Indikator für gutes oder schlechtes Coding. Denn dann wäre der 1-Zeiler ( 1 Befehl ) deinem 4-Zeiler überlegen.
Insofern sehe ich kürzeren Code zwar nicht als zwingenden Beweis, wohl aber als starkes Indiz auf besser lesbaren Code an.
Hallo zusammen,
vielen Dank für Eure Hilfe. Ihr habt recht, mein Code bei manchen Stellen sieht nicht so schön aus. Ich werde es verbessern. Zu dem Problem, warum war mein Programm hängen geblieben. Ich habe herausgefunden, dass FUBA SAPGUI_PROGRESS_INDICATOR zu oft aufgerufen wurde. Es gibt bei dem Code 2 LOOPS und nach jedem LOOP habe ich SAPGUI_PROGRESS_INDICATOR eingebaut und es hat Probleme gemacht. Dann habe ich bei der 2.LOOP nur je 1000.Schleife ein mal FUBA SAPGUI_PROGRESS_INDICATOR aufgerufen. Dann ging es.
cuncon
vielen Dank für Eure Hilfe. Ihr habt recht, mein Code bei manchen Stellen sieht nicht so schön aus. Ich werde es verbessern. Zu dem Problem, warum war mein Programm hängen geblieben. Ich habe herausgefunden, dass FUBA SAPGUI_PROGRESS_INDICATOR zu oft aufgerufen wurde. Es gibt bei dem Code 2 LOOPS und nach jedem LOOP habe ich SAPGUI_PROGRESS_INDICATOR eingebaut und es hat Probleme gemacht. Dann habe ich bei der 2.LOOP nur je 1000.Schleife ein mal FUBA SAPGUI_PROGRESS_INDICATOR aufgerufen. Dann ging es.
cuncon
Vergleichbare Themen
14
Antw.
Antw.
2924
Views
Views
2
Antw.
Antw.
1238
Views
Views
18
Antw.
Antw.
6936
Views
Views
8
Antw.
Antw.
4556
Views
Views
Speicher & Performance Problem bei XML einlesen
von Zubasa » 15.06.2011 13:48 • Verfasst in ABAP® für Anfänger
von Zubasa » 15.06.2011 13:48 • Verfasst in ABAP® für Anfänger
5
Antw.
Antw.
3379
Views
Views
Performance-Problem bei Aufruf einer SAP-Klasse
von xforce » 12.07.2018 13:19 • Verfasst in ABAP® für Anfänger
von xforce » 12.07.2018 13:19 • 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.