Da hast Du wohl schon länger nicht mehr in die F1-Hilfe zu COLLECT geschaut.black_adept hat geschrieben:@DrAbap:
Da ich bisher noch nie mit HashTables gearbeitet führen mich Ihre Ausführungen zu folgendem Schluss:
Wenn ich ein COLLECT in eine Hashtabelle mache müsste dies doch einen enormen Geschwindigkeitszuwachs geben verglichen mit einem COLLECT in eine Standardtabelle, oder?
Der Zugriff bei READ ... WITH KEY hängt (s. F1-Hilfe zu READ) bei nicht sortierten Tabellen linear, bei Sortierten tabellen logarithmisch, bei hashtabellen gar nicht von der Anzahl Tabellenzeilen ab.@hsv:
Sehe ich ähnlich - außer dass man sich den Zusatz "Binary Search" spart.
Aber die Sorted-Tables haben zumindest für mich 2 Vorteile:
1.) Wenn sie -warum auch immer - nicht sortiert sind teilt mir das System dies automatisch mit. ( :D mit einem Kurzdump :D )
2.) Wenn ich geschachtelte LOOPs habe ist es SEHR viel performanter wenn die innere Schleife via "WHERE"-Bedingung durchlaufen wird und diese einen Teilschlüssel der durchlaufenen Tabelle darstellt.
Code: Alles auswählen.
* Entries: 100 (ITAB1), 1000 (ITAB2)
* Line width: 100
* Both tables sorted by key K
LOOP AT ITAB1 INTO WA1.
LOOP AT ITAB2 INTO WA2
WHERE K = WA1-K.
" ...
ENDLOOP.
ENDLOOP.
Code: Alles auswählen.
* Entries: 100 (ITAB1), 1000 (ITAB2)
* Line width: 100
* Both tables sorted by key K
I = 1.
LOOP AT ITAB1 INTO WA1.
LOOP AT ITAB2 INTO WA2 FROM I.
IF WA2-K <> WA1-K.
I = SY-TABIX.
EXIT.
ENDIF.
" ...
ENDLOOP.
ENDLOOP.
DRABAP hat geschrieben:In ABAP gibt es drei versiedene Arten von internen Tabellen. Die richtige Verwendung kann entscheidend für die Performance eines Programmns sein. Im folgenden werden ein paar typische Anwendungsszenarien beschrieben.
Hashtabellen bieten im allgemeinen die beste Performance beim Zugriff. Wenn man sie verwenden kann sollte man es tun. Leider gibt es einige Einschrenkung hinsichtlich ihrer Einsetzbarkeit. Hashtabellen müssen einen eindeutigen Schlüssel besitzen. Es können also keine Duplikate gespeichert werden. Der Zugriff ist nur dann effizient, wenn der volle Schlüssel spezifiziert wird. Die Perfromance ist dann unabhängig von der Größe. Wird nicht der volle Schlüssel verwendet ist die Perfromance linear von der Größe der Tabelle abhändig. Hashtabellen besitzen eine Reihenfolge und können auch sortiert werden.
Sortierte Tabelle können Duplikate speichern. Sie bieten einen effizenten Lesezugriff, der nur sehr in geringem Maße von der Größe der Tabelle abhängt. Dies ist allerdings nur der Fall, wenn der volle Schlüssel oder ein Anfangsstück des Schlüssels angeben wird. Sortierte Tabellen besitzen natürlich eine feste Reihenfolge. Sie können allerdings nur gemäß ihres Schlüssels sortiert werden, was allerdings nicht nötig ist, da seei ohnehin sortiert sind).
Standardtabelle bieten nur einen ineffizenten Lesezugriff (die gesamte Tabelle wird sequentiell durchsucht). Es gibt allerdings einige Dinge, die nur mit Standardtabellen funktionieren wie z.B. der RFC (in älteren Releases). Will man beim lesen eine bessere Effiziens erreichen, so muß man die Tabelle sortieren und dann den READ ... BINARY SERACH verwenden. Hierbei sind jedoch einige Fallstricke zu beachten. Trotzdem ist zu sagen: wenn man oft mit verschiedenen Schlüsseln suchen will, bieten sich Standardtabellen an. Man kann die Tabelle dann jeweils einmal gemäß des Schlüssels sortieren und dann die effiziente Binärsuche verwenden. Standardtabellen sind also sehr flexibel.
Damit ergeben sich doch folgende Formeln für eine Tabelle mit N Zeilen:Anonymous hat geschrieben: Der Zugriff bei READ ... WITH KEY hängt (s. F1-Hilfe zu READ) bei nicht sortierten Tabellen linear, bei Sortierten tabellen logarithmisch, bei hashtabellen gar nicht von der Anzahl Tabellenzeilen ab.
Insofern gibt es schon je nach Anwendung Optimierungsmöglichkeiten.