ABAP Performance-Tipps 4.6 - Februar 2007

Der folgende Abschnitt dient für mich hauptsächlich als Nachschlagewerk, deshalb ist er nur knapp mit den wesentlichen Informationen versehen und die Beispiele sind arg verkürzt. Wer es genauer wissen will sollte im Buch ABAP Performance Workshop (siehe Bücherliste ) nachschlagen. Diese Tipps sind Stand Anfang 2007 und basieren auf den Empfehlungen des Buches angereichert um meine eigenen Erfahrungen und Ansichten. Im Vergleich zu den ABAP Performance-Tipps 7.0 lassen sich deutliche Unterschiede herauslesen. Das ist zum Einen der sich fortentwickelnden Technik zu verdanken, zum Anderen aber auch ist es Ansichtssache. Und da es zwei verschiedene Autoren mit völligen unterschiedlichem Ansatz und Herkunft sind ist das auch absolut erklärlich. Die Version 4.6 wurde von einem externen SAP-Entwickler geschrieben und war damals das einzige Buch zu diesem Thema. Das hat dann auch die SAP erkannt. Die Version 7.0 dagegen kommt direkt von der SAP. Der Autor kommt direkt von der SAP, er berät dort die SAP Entwicklungsabteilung in Performancefragen.

Also hier die veralteten Hinweise, Stand 4.6, für den, der das vergleichen möchte (in blau Hinweise zu neueren Erkenntnissen, Erweiterungen):

möglichst präzise, möglichst nur die unbedingt benötigten Daten selektieren; nicht wiederholt die gleichen Daten lesen
KEIN select *, nur wenn wirklich alle Spalten benötigt werden! Ansonsten immer alle Spalten benennen! Besser select bookid customid from sbook into (sbook-bookid, sbook-customid) where carrid = S_carrid.
noch besser INTO struktur : data:beginn of struktur, bookid type sbook-bookid, customid type sbook-customid, end of struktur.
Vorsicht bei 'into corresponding fields of mara'
ggfls. statt INTO besser APPENDING nehmen
SELECT field INTO TABLE tabname nicht bei Speicherengpässen (große Mengen)
der JOIN ist dein Freund (jedoch Laufzeit testen!) - Vorsicht kann tückisch sein
ORDER-BY umgeht die Pufferung von Tabellen!
ggfls. Datenbank-View anlegen und benutzen
keine Nutzung von ON CHANGE OF
PACKING SIZE verwenden wenn Daten unsortiert von der DB übernommen werden können, ggfls. EXTRACT
nur in Ausnahmefällen Verwenden eines CURSOR (siehe Beispieldatenbank Report DEMO_SELECT_CURSOR_1 bis 3)
Laufzeitmessungen immer TAGSÜBER zur Besten Sendezeit machen! Diesen Wert vergleichen mit wenn niemand da ist.
bei doppelten Schlüsseln und > 4000 Datensätzen: into STANDARD TABLE und SORT <itab>
optimale WHERE-Klausel: aktive Indizes beachten
Aggregatfunktionen COUNT, SUM, MIN, MAX, AVG nutzen
UPDATE tabname SET tabfeld = 'X'
DELETE FROM tabname WHERE tybfeld = 'X'
UPDATE tabname FROM TABLE itab
DELETE tabname FROM TABLE itab
INSERT tabname FROM TABLE itab
Kontext verwenden [SE33] (Einzelsatzbehandlung, Dialog) - obsolet
Abfangen der Benutzereingabe 'einmal alles' bei AT SELECTION-SCREEN {Komfort: SET CURSOR FIELD s_field-low}
ggfls. Laufzeitabschätzung bei AT SELECTION-SCREEN
Verwenden von OBLIGATORY bei select-options und parameters
POPUP_TO_DECIDE für Hintergrundausführung anbieten [Fubau JOB_OPEN, SUMIT {anderes Muster}... VIA JOB, Fubau JOB_CLOSE; siehe auch zpws0022.txt]
unnötige Typumwandlungen vermeiden, auch bei Rechenoperationen und Datendeklarationen
nur das Benötigte loopen: ASSIGNING benutzen, sonst LOOP AT itab TRANPORTING field1 field2.
nur das Benötigte modifizieren: MODIFY ityb TRANSPORTING field1.
breite interne Tabellen mit Pointern bearbeiten (keine Kopfzeile nötig; ASSIGNING <fs>)
richtigen internen Tabellentyp verwenden: Standard-Tabelle bei Indexzugriffen, bei reinen Schlüsselzugriffen Hashed-Tabelle {READ...WITH KEY} und Sorted-Table bei LOOP AT ...WHERE.
logische Datenbank nur wenn immer fast alle Daten gelesen werden, sonst Bottum-Up-Ansatz: das stärkte Filterkriterium zuerst lesen - obsolet bzw. nicht objektorientiert

Die generelle Reihenfolge ist Datenbank, Puffer, interne Tabellen. Bei der Datenbank gibt es viel anzumerken: u.a. dass die Reihenfolge auch ganz wichtig ist. Die dramatischsten Performanceprobleme sind fehlende Indizes, oder allgemeiner zu langsame Suchen. Ebenfalls dramatisch kann es sein, wenn viel zu viel gelesen wird, zu wenig einschränkende WHERE-Bedingung, leere FOR ALL ENTRIES Tabelle.

HTH