Performance-Problem
Beitrag
von black_adept (Top Expert / 3946 / 105 /
886
)
»
*Ohne System, daher evtl. nicht ganz syntaxfehlerfrei - aber so geht es etwa:DeathAndPain hat geschrieben: Es ist kein absolut zwingender Zusammenhang, aber in den allermeisten Fällen ist der kürzere Code auch der besser lesbare.
<gs_output>-ovflag = cond #( WHEN line_exists( gt_bestandliste_temp[ best_idx + 1 ] ) THEN cond #( WHEN gt_bestandliste_temp[ best_idx + 1 ]-planr <> <gs_bestandsliste>-planr THEN 'X' ELSE <gs_output>-ovflag ) ELSE <gs_output>-ovflag ).
Nur ein Befehl/[lange] Zeile - aber wirklich besser lesbar?
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von DeathAndPain (Top Expert / 1797 / 214 /
396
)
»
Das hängt davon ab, wie man es niederschreibt. Du kannst auch einen kompletten SELECT mit INTO, FROM, JOIN und WHERE in eine Zeile schreiben; das sieht dann auch scheußlich aus, obgleich der SELECT als solcher durchaus sachgerecht sein kann. Ähnliches gilt z.B. auch für Aufrufe von Funktionsbausteinen mit ihren ganzen Parametern. Komplexere Befehle muss man halt über mehrere Zeilen verteilen, damit sie lesbar sind.
Ich würde Deinen Code so schreiben:
Dann finde ich das durchaus gut lesbar - allerdings ist das dann nicht mehr eine Zeile lang und hat in meinen Augen keine Vorteile mehr gegenüber meiner Version (weswegen ich es auch nicht so vorgeschlagen habe).
Was ich nicht weiß, ist, was der Pretty Printer daraus machen würde, da ich diesen bei mir so eingestellt habe, dass er nur auf Großschreibung umsetzt (3.1i-Style
) und ansonsten die Finger von dem Code lässt. Wenn der Pretty Printer einem hier die Optik ruinieren sollte, dann stelle ich mich hinter Daniel und sage, von dem sollte man die Finger lassen. Vielleicht ist der Pretty Printer aber auch so pfiffig programmiert, dass er hier eine vielleicht etwas andere, aber dennoch lesbare Variante wählt. Alles in eine Zeile ist IMHO bei keinem COND oder SWITCH angemessen. Wenn der Pretty Printer das machen sollte, wäre es ein Versagen auf seiner Seite.
Dieser Include kommt bei mir in jeden Code rein, der einen Progress Indicator mit hochzählender Uhr braucht. So kriege ich den komfortabel und mit wenigen Handgriffen in jedes Programm rein. In meinen Augen eine gut vertretbare Anwendung eines Makros.
Ich würde Deinen Code so schreiben:
Dann finde ich das durchaus gut lesbar - allerdings ist das dann nicht mehr eine Zeile lang und hat in meinen Augen keine Vorteile mehr gegenüber meiner Version (weswegen ich es auch nicht so vorgeschlagen habe).
Was ich nicht weiß, ist, was der Pretty Printer daraus machen würde, da ich diesen bei mir so eingestellt habe, dass er nur auf Großschreibung umsetzt (3.1i-Style
) und ansonsten die Finger von dem Code lässt. Wenn der Pretty Printer einem hier die Optik ruinieren sollte, dann stelle ich mich hinter Daniel und sage, von dem sollte man die Finger lassen. Vielleicht ist der Pretty Printer aber auch so pfiffig programmiert, dass er hier eine vielleicht etwas andere, aber dennoch lesbare Variante wählt. Alles in eine Zeile ist IMHO bei keinem COND oder SWITCH angemessen. Wenn der Pretty Printer das machen sollte, wäre es ein Versagen auf seiner Seite.Ich habe mir schon vor langer Zeit den folgenden Include gebaut:cuncon hat geschrieben: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.
Code: Alles auswählen.
*&---------------------------------------------------------------------*
*& Include ZINDIKAT
*&---------------------------------------------------------------------*
* Benutzungshinweise: Die Variablen I, AI und GES müssen als TYPE I definiert sein. Vor einem aufwendigeren LOOP über
* eine interne Tabelle xyz schreibt man dann folgende Zeilen (natürlich ohne Kommentarzeichen):
* DESCRIBE TABLE xyz LINES GES.
* CLEAR AI.
* Dann kann man im LOOP als ersten Befehl einfach
* PROGRESS_INDICATOR 'Berechnung findet statt'
* schreiben und bekommt dadurch eine Statusanzeige mit sauber hochzählender Prozentzahl.
* Die Einschränkung auf 5-Prozent-Schritte dient zur Performanceverbesserung, damit LOOPS über 1000 oder mehr
* Tabellenzeilen nicht tausendmal mit dem Client GUI kommunizieren. Ansonsten leidet nämlich die Performance merklich.
DEFINE PROGRESS_INDICATOR.
I = 100 * SY-TABIX / GES - 5.
IF I = 0. I = 1. ENDIF. " gleich beim ersten Durchlauf Uhr anzeigen
IF I > AI.
ADD 5 TO I. " nur alle 5 Prozent GUI-Sanduhr aktualisieren
CALL FUNCTION 'SAPGUI_PROGRESS_INDICATOR'
EXPORTING PERCENTAGE = I
TEXT = &1.
MOVE I TO AI.
ENDIF.
END-OF-DEFINITION.
Beitrag
von ralf.wenzel (Top Expert / 3776 / 176 /
262
)
»
Warum nichtDeathAndPain hat geschrieben:Code: Alles auswählen.
DESCRIBE TABLE xyz LINES GES.
Code: Alles auswählen.
ges = lines( xyz ).Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von black_adept (Top Expert / 3946 / 105 /
886
)
»
Das Coding passt nicht zum Kommentar "gleich beim 1. Durchlauf Uhr anzeigen":DeathAndPain hat geschrieben:Code: Alles auswählen.
* DESCRIBE TABLE xyz LINES GES. * CLEAR AI. ... DEFINE PROGRESS_INDICATOR. I = 100 * SY-TABIX / GES - 5. IF I = 0. I = 1. ENDIF. " gleich beim ersten Durchlauf Uhr anzeigen IF I > AI. ADD 5 TO I. " nur alle 5 Prozent GUI-Sanduhr aktualisieren CALL FUNCTION 'SAPGUI_PROGRESS_INDICATOR' EXPORTING PERCENTAGE = I TEXT = &1. MOVE I TO AI. ENDIF. END-OF-DEFINITION.
Beispiel: 1. Durchlauf, Tabelle hat 100 Zeilen
I = 100 * sy-tabix / GES - 5 = 100 * 1 / 100 - 5 = -4
--> IF I > AI ist nicht wahr --> es wird kein Progressindikator aufgerufen
Beitrag
von DeathAndPain (Top Expert / 1797 / 214 /
396
)
»
Weißt Du, wie alt dieser Include ist?ralf hat geschrieben:Warum nicht
Code: Alles auswählen
ges = lines( xyz ).
Sieht aus wie jede andere Zuweisung.....
Der hat so schon unter 3.1i funktioniert. Damals gab es Deine Syntax noch nicht. Heute würde ich ihn etwas anders schreiben, ja.Hast recht, ist ein Bug, der aber all die Jahre nicht wirklich aufgefallen ist. Vielleicht eine gute Gelegenheit, das Coding mal zu moderniseren.black_adept hat geschrieben:Das Coding passt nicht zum Kommentar "gleich beim 1. Durchlauf Uhr anzeigen"
Der Kommentartext war aber anders gemeint; daran erinnere ich mich (aus welchen Gründen auch immer) noch. Und zwar wollte ich verhindern, dass der FB bei hinreichend großen Tabellen anfangs mit PERCENTAGE = 0 aufgerufen wird. Dann zeigt er nämlich gar keine Uhr an, sondern nur den Text! Und dass ist natürlich blöd, wenn er mit demselben Text im weiteren Verlauf dann hochzählt. Das hat also nichts mit Deinem (berechtigten) Einwand zu tun, dass anfangs der FB gar nicht erst aufgerufen wird.
Beitrag
von DeathAndPain (Top Expert / 1797 / 214 /
396
)
»
Ich habe das Coding jetzt überarbeitet. Hier ist der neue Code:
Code: Alles auswählen.
*&---------------------------------------------------------------------*
*& Include ZINDIKAT
*&---------------------------------------------------------------------*
* Benutzungshinweise: Die Variablen I, AI und GES müssen als TYPE I definiert sein. Vor einem aufwendigeren LOOP über
* eine interne Tabelle xyz schreibt man dann folgende Zeilen (natürlich ohne Kommentarzeichen):
* GES = LINES( xyz ).
* CLEAR AI.
* Dann kann man im LOOP als ersten Befehl einfach
* PROGRESS_INDICATOR 'Berechnung findet statt'
* schreiben und bekommt dadurch eine Statusanzeige mit sauber hochzählender Prozentzahl.
* Die Einschränkung auf 5-Prozent-Schritte dient zur Performanceverbesserung, damit LOOPs über 1000 oder mehr
* Tabellenzeilen nicht tausendmal mit dem Client GUI kommunizieren. Ansonsten leidet nämlich die Performance merklich.
DEFINE PROGRESS_INDICATOR.
I = TRUNC( 99 * SY-TABIX / GES ) + 1.
IF I > AI.
CALL FUNCTION 'SAPGUI_PROGRESS_INDICATOR'
EXPORTING PERCENTAGE = I
TEXT = &1.
AI = I + 4. " 5%-Schritte machen
ENDIF.
END-OF-DEFINITION.
Beitrag
von black_adept (Top Expert / 3946 / 105 /
886
)
»
D&P: Jetzt ist das Coding zwar überarbeitet - aber man sieht, dass du es auf die Schnelle gemacht hast. Was rausgekommen ist, ist ein typisches Beispiel für unleserliches Coding. Du willst eine Prozentzahl ermitteln. Da kann man doch nicht mit 99 multiplizieren und nachher noch +1 rechnen, damit komische Symptome dann korrigiert werden. Die Prozentzahl die du haben willst ist immer! 100 * sy-tabix / GES. Alles andere an der Formel ( TRUNC, 99, +1 ) ist Flickschusterei und wer das warten soll kratzt sich am Kopf was du da Seltsames fabriziert. Der Teil den du jetzt weggelassen hast um die Sanduhr auch bei 0% anzuzeigen war viel aussagekräftiger.
Gewissermaßen macht das tatsächlich 5% Schritte - aber nur nachdem man sich durch das Coding gequält hat und die ganze >-Zeichenarie auswertet . Egal was du hier machst - wenn du 5%-Schritte haben willst dann verwende eine 5 ( und dann halt >= an den richtigen Stellen ).
Code: Alles auswählen.
I = TRUNC( 99 * SY-TABIX / GES ) + 1.Code: Alles auswählen.
AI = I + 4. " 5%-Schritte machen
Beitrag
von ralf.wenzel (Top Expert / 3776 / 176 /
262
)
»
Ich fände eine Methode auch besser als ein Makro..... Kann man auch zentral warten und ich bin kein besonderer Freund von Makros. Ab in eine Serviceklasse damit als statische Methode und gut is.
Ralf
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von black_adept (Top Expert / 3946 / 105 /
886
)
»
Gut gebrüllt, Löwe. Aber statt hier so was zu postulieren würde mich für diesen ganz speziellen Fall doch mal interessieren, wie so eine Serviceklasse aussehen soll, die sowohl handhabbar als auch laufzeittechnisch mit D&Ps Include mithalten kann, wenn dieser denn mal sauber ausprogrammiert gepostet würde ( also auch mit der Datendefinition für GES, AI und I bzw. sinnvoll benannten Pendants im Include ). Denn so einfach wie du das hier darstellst ist das m.E. gar nicht.ralf.wenzel hat geschrieben:Ich fände eine Methode auch besser als ein Makro..... Kann man auch zentral warten und ich bin kein besonderer Freund von Makros. Ab in eine Serviceklasse damit als statische Methode und gut is.
Beitrag
von ralf.wenzel (Top Expert / 3776 / 176 /
262
)
»
Also, zunächst mal habe ich keine Veranlassung, anzunehmen, dass eine statische Methode grundsätzlich inperformanter ist als ein Makro. Was ich weiß, ist: Ein Makro kann man nicht debuggen und subjektiv schwerer lesbar ist es auch noch (und das geht nicht nur mir so). Eigentlich konnte mir noch niemand erklären, welchen Vorteil ein Makro hat.
Aber ich bin ja lernfähig....
Ralf
Aber ich bin ja lernfähig....
Ralf
Folgende Benutzer bedankten sich beim Autor ralf.wenzel für den Beitrag:
a-dead-trousers
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von a-dead-trousers (Top Expert / 4285 / 214 /
1141
)
»
(Ganz) früher hab ich die verwendet um wiederkehrende Code-Abschnitte, die mit Feld-Symbolen in Methoden arbeiten zu "parametrisieren". Inzwischen gibt es ja Gottseidank den Zusatz REFERENCE INTO zu diversen Befehlen und somit auch eine OO-konforme Alternative zu den Feld-Symbolen die über Methodengrenzen hinweg funktioniert. Ich hätte damals zwar auch GET REFERENCE verwenden können, aber erst seit REFERENCE INTO hab ich die Sinnhaftigkeit dahinter verstanden. (Brett vorm Kopf usw.)ralf.wenzel hat geschrieben:Eigentlich konnte mir noch niemand erklären, welchen Vorteil ein Makro hat.
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
Beitrag
von ralf.wenzel (Top Expert / 3776 / 176 /
262
)
»
Kannst du das mal bitte etwas konkreter ausführen? Dein Posting verstehe ich nicht.
Ralf
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von black_adept (Top Expert / 3946 / 105 /
886
)
»
Du drückst dich vor einer Antwort. Poste doch bitte mal ein Coding welches das macht was D&P gepostet hat als statische Methode. Und danach den Aufruf ebendieser. Wahrscheinlich merkst du schon beim Versuch so eine Methode zu erstellen was der Vorteil des Makros in diesem ganz speziellen Fall ist.ralf.wenzel hat geschrieben:Also, zunächst mal habe ich keine Veranlassung, anzunehmen, dass eine statische Methode grundsätzlich inperformanter ist als ein Makro. Was ich weiß, ist: Ein Makro kann man nicht debuggen und subjektiv schwerer lesbar ist es auch noch (und das geht nicht nur mir so). Eigentlich konnte mir noch niemand erklären, welchen Vorteil ein Makro hat.
Aber ich bin ja lernfähig....
Ralf
Beitrag
von ralf.wenzel (Top Expert / 3776 / 176 /
262
)
»
Ich drücke mich nicht vor der Antwort, ich habe die Frage gestellt (die, welchen Vorteil ein Makro hat). Bei uns ist der FB in einer Methode verschalt, die Dialog-Kollegen nutzen diese Methode, ich nicht. Weil ich eher „unter der Haube“ programmiere (ich schreibe eher Testverfahren zur automatischen Validierung). Meine Dialoge sind so klein, dass ich keine Anzeige brauche.
Ralf
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von black_adept (Top Expert / 3946 / 105 /
886
)
»
Dann ist die Antwort einfach für diesen Fall: Weil der Aufruf schlanker ist als beim Aufruf einer alternativen statischen Methode[ und wahrscheinlich sogar unwesentlich performanter ].ralf.wenzel hat geschrieben:Ich drücke mich nicht vor der Antwort, ich habe die Frage gestellt (die, welchen Vorteil ein Makro hat).
Vergleichbare Themen
2
Antw.
Antw.
1058
Views
Views
14
Antw.
Antw.
2549
Views
Views
18
Antw.
Antw.
6525
Views
Views
8
Antw.
Antw.
4228
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
1
Antw.
Antw.
152
Views
Views
Laden Archivierter Daten - Performance Problem
von tom125 » 03.02.2021 10:44 • Verfasst in ABAP® für Anfänger
von tom125 » 03.02.2021 10:44 • 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.