Performance-Problem

Performance-Problem

Re: Performance-Problem

Re: Performance-Problem

Re: Performance-Problem

Re: Performance-Problem

zzcpak hat geschrieben:nur mal als Verdacht, da ich nicht weiß, unter welchem Release-Stand dein Programm arbeitet.

Der Funktionsbaustein MD_STOCK_REQUIREMENTS_LIST_API hatte mal den Fehler, alte Daten zu liefern. Ursache war ein fehlendes CLEAR/REFRESH auf die Tabellenparameter des Funktionsbausteines.

Siehe dazu SAP-Hinweis https://launchpad.support.sap.com/#/corrins/396372/1
Der ist allerdings steinalt und für 46B/46C gültig. Aber es soll ja noch solche Installationen geben, auch produktiv.

Sonst prüf doch spaßeshalber mal im Debugger, ob deine interne Tabelle GT_BESTANDSLISTE auch noch die Daten des vorigen Laufes enthält, bzw. ob diese im Funktionsbaustein geleert wird.

Re: Performance-Problem

ralf.wenzel hat geschrieben:Ich hab gerade nur begrenzt Zeit, aber ich hab mal draufgeguckt, ob mir was auffällt. Ein paar Dinge sind mir aufgefallen.

Die Bestandsliste ist eine Standardtabelle, weil sie als solche aus dem Funktionsbaustein rauskommt - ich würde sie umkopieren in eine Tabelle mit einem entsprechenden Schlüssel auf DELB0. Außerdem würde ich darauf achten, dass die MATNR in GT_OUTPUT jeweils einmalig ist (damit du nicht für dieselbe Mateiralnummer das Zeugs mehrfach durchläufst).

Wenn man länger guckt, findet man sicher noch mehr

Zum Beispiel KÖNNTE man die Bestandslisten in einer großen Tabelle sammeln (insert linse of gt_bestandsliste into table gt_bestandsliste_gesamt, über DIE machst du dann den LOOP), je größer die Tabelle ist, umso eher bringen die Schlüssel was, würde ich meinen.

Insbesondere kannst du die beiden LOOPs dann hintereinander machen und musst sie nicht "ineinander" machen. Zu den Feldsymbolen: Es gibt in meinen Augen keinen Grund, KEINE Feldsymbole zu verwenden und je größer die Tabellen sind, umso eher bringen Feldsymbole was.

Das wären also meine drei ersten Tipps: Auf einmalige MATNRn achten, im LOOP AT gt_output nur den FuBau aufrufen und die gt_bestandsliste sammeln einer großen itab, die einen entsprechenden Schlüssel haben sollte, damit der LOOP AT WHERE auch wirklich nur für die Sätze angesprungen wird, für den die WHERE Bedingung auch gilt und die LOOPs hintereinander machen statt "ineinander".


Ralf

Re: Performance-Problem

black_adept hat geschrieben:

cuncon hat geschrieben:

Code: Alles auswählen.

            "Kennzeichen "X" setzen, wenn Kundenauftragsbestände ohne Vorgang existieren, dh, wenn mng01 <> 0 und nächste Eintrag ist auch KD-BST und hat nicht gleiche planr

Mal abgesehen von der Performance. Wenn der Code das tun soll, was in dem Kommentar gesagt wird, dann tut er das nur zufällig. Grund: Du fragst nicht ab ob die folgende Zeile auch "KD-BST" ist. Außerdem die Frage: Ist garantiert, dass das Sortieren und Löschen das du machst die Reihenfolge die der FuBa zurückgegeben hat nicht ändert?

Re: Performance-Problem

DeathAndPain hat geschrieben:Also das ist alles noch keine zufriedenstellende Erklärung. Was Du da im inneren LOOP machst, ist performancetechnisch eigentlich ein Lacher. Das sollte nicht auf einen Timeout laufen, selbst wenn gt_bestandliste 60.000 Einträge hätte! Da muss noch irgendwo anders der Hund begraben sein.

Allerdings finde ich den Inhalt der Tabelle gt_bestandliste gar nicht so interessant, denn der ändert sch ja mit jedem Durchlauf der äußeren Tabelle. Wieviel ist denn in gt_output drin? Das ist doch viel wichtiger, denn das multipliziert sich ja mit den jeweiligen Einträgen aus gt_bestandliste aus! Im übrigen wird der Funktionsbaustein so oft durchlaufen, wie gt_output Zeilen hat. Und den FB habe ich viel mehr im Verdacht, Laufzeit zu ziehen! Der wird vermutlich auch Datenbankzugriffe machen.

Die anderen Optimierungen sind nett, aber nur Kleinkram. Was Du dabei noch machen kannst:

Code: Alles auswählen.

SORT gt_bestandliste BY delb0 DESCENDING.
DELETE gt_bestandliste WHERE delb0 = 'AR-RES'.

Du sortierst die AR-RES-Zeilen erst aufwändig rein, um sie anschließend rauszulöschen. Würde ich gefühlsmäßig andersrum machen: Erst die unnützen Zeilen rauslöschen, und dann nur den interessanten Rest sortieren. Aber vielleicht ist Dein Weg sogar schneller, weil er so nur einmal sequenziell durch die Tabelle muss. Müsste man mal austesten. Hängt sicherlich auch davon ab, wie viele AR-RES-Zeilen es in der Tabelle gibt. Taugt aber auch nicht als zufriedenstellende Erklärung für Deinen Tmeout.

Aber wie Ralf schon sagte, ein LOOP WHERE hat (im Gegensatz zum READ TABLE mit BINARY SEARCH) nur dann etwas von einer Sortierung, wenn die Tabelle selbst als SORTED definiert ist. Dabei tunlichst genau den Tabellenschlüssel festlegen, mit dem Dein LOOP später suchen wird. Wobei ich befürchte, dass mit dem OR der Sortierungsvorteil auch wieder den Bach runtergeht; das wird der LOOP so nicht nutzen können. Der Aufzählungs-IN, den der SELECT-Befehl kennt, wird vom LOOP leider nicht unterstützt. Da müsstest Du Dir eine RANGES-Tabelle mit den möglichen Werten für delb0 aufbauen und dann LOOP AT gt_bestandsliste WHERE delbo IN deine_ranges_tabelle schreiben. Dann könnte die Optimierung klappen.

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.

Aber wie gesagt, als erstes mal klären, wieviel Zeilen gt_output hat.