
ABAP - Interne Tabellen (Beispiel)
Die Performance beim Zugriff auf interne Tabellen kann je nach Zugriff variieren. Wie du deine Zugriffe und die Zeiten überprüfst, zeigen wir dir in diesem Artikel.
Inhaltsverzeichnis
In den bisherigen Artikeln haben wir über das Thema Performance und Zugriffe gesprochen. Heute wollen wir die Frage mit dir klären, welcher der Zugriffe nun schneller oder einfacher ist und wie du es für dich messen kannst.
Vorbereitung
Zur Vorbereitung des Test definieren wir die Tabellen für den Zugriff. Jede einzelne Tabelle wird für einen Zugriff verwendet und stellt eine Zugriffsart dar.
" Definition der Tabellen
DATA:
ld_tab TYPE string,
lt_sttab TYPE STANDARD TABLE OF t001,
lt_sotab TYPE SORTED TABLE OF t001 WITH UNIQUE KEY bukrs,
lt_hatab TYPE HASHED TABLE OF t001 WITH UNIQUE KEY bukrs,
lt_bitab TYPE STANDARD TABLE OF t001,
lt_ketab TYPE STANDARD TABLE OF t001 WITH NON-UNIQUE SORTED KEY sec COMPONENTS bukrs.
Dann lesen wir die Daten für unseren Zugriff aus der T001 (Buchungskreise). In diesem Fall reicht es alle Einträge zu lesen und diese dann zu übernehmen, da wir gegen alle Einträge lesen wollen.
" Lesen der Daten
SELECT *
FROM t001
INTO TABLE @lt_sttab.
" Übernahme der Daten
lt_sotab = lt_sttab.
lt_hatab = lt_sttab.
lt_bitab = lt_sttab.
SORT lt_bitab BY bukrs.
lt_ketab = lt_sttab.
Bei der Tabelle lt_bitab handelt es sich um eine Standard Tabelle, deshalb sollten wir noch einmal die Tabelle nach dem definierten Schlüssel sortieren, da sonst nicht sichergestellt ist, dass die Tabelle nach dem Lesen wirklich die richtige Sortierung hat.
Durchführung
Für unseren Test haben wir sechs Fälle vorbereitet, die wir testen möchten:
- Standard Tabelle
- Sortierte Tabelle
- Hash Tabelle
- Ein Read mit Binary Search
- Standard Tabelle mit zweitem Schlüssel ohne Angabe
- Standard Tabelle mit zweitem Schlüssel mit Angabe
" Verarbeitung der Methoden
DO 6 TIMES.
DATA(ld_index) = sy-index.
" Start der Messung
GET RUN TIME FIELD DATA(ld_start).
LOOP AT lt_sttab INTO DATA(ls_data).
" Methode festlegen
CASE ld_index.
WHEN 1.
ld_tab = 'Standard'.
DATA(ls_bukrs) = lt_sttab[ bukrs = ls_data-bukrs ].
WHEN 2.
ld_tab = 'Sorted'.
ls_bukrs = lt_sotab[ bukrs = ls_data-bukrs ].
WHEN 3.
ld_tab = 'Hashed'.
ls_bukrs = lt_hatab[ bukrs = ls_data-bukrs ].
WHEN 4.
ld_tab = 'BinarySearch'.
READ TABLE lt_bitab INTO ls_bukrs
WITH KEY bukrs = ls_data-bukrs
BINARY SEARCH.
WHEN 5.
ld_tab = 'SecondaryKey ohne Angabe'.
ls_bukrs = lt_ketab[ bukrs = ls_data-bukrs ].
WHEN 6.
ld_tab = 'SecondaryKey mit Angabe'.
ls_bukrs = lt_ketab[ KEY sec COMPONENTS bukrs = ls_data-bukrs ].
ENDCASE.
ENDLOOP.
" Abschluss der Messung
GET RUN TIME FIELD DATA(ld_end).
WRITE: / |Messung { ld_tab }: { ld_end - ld_start }|.
ENDDO.
Über Get Runtime lesen wir die verbrauchte Zeit am Anfang und am Ende ein und vergleichen das Ergebnis.
Ergebnis
Wir wir bereits im letzten Artikel beschrieben haben, sind die Zugriffe mit definierten Schlüsseln oder dem Binary Search am Schnellsten. Dazu das Ergebnis nach der Ausführung des Reports (mit ca. 4500 Datensätzen) in drei verschiedenen Läufen, um das variierende Ergebnis besser darzustellen.
Fazit
Du solltest bei den Zugriffen auf interne Tabellen immer darauf achten, dass du auch den richtigen Schlüssel definiert hast oder sicherstellen, dass die Tabelle nicht viele Datensätze enthält. Wie unsere Tests gezeigt haben, ist es aber gar nicht so wichtig, was für einen Schlüssel du verwendest, Hauptsache, es ist überhaupt einer definiert.