So optimieren Sie die Leistung dieses ABAP-Codes

Question

Meine interne Tabelle enthält eine Menge Daten. Ich habe den folgenden Code:

LOOP AT lt_tab INTO ls_tab 
    WHERE ((value1 EQ lv_id1) AND 
    (value2 LE lv_id2 AND value3 GE lv_id3)). 

    IF ls_tab-value4 IS NOT INITIAL. 
    IF ls_tab-value4 NE lv_var. 
     lv_flag = lc_var. 
     EXIT. 
    ENDIF. 
    ELSE. 
    lv_flag = lc_var. 
    EXIT. 
    ENDIF. 
ENDLOOP. 

Die Datenbanktabelle enthält 7 Felder und die interne Tabelle hat den gleichen Typ wie die Datenbanktabelle. In der Where-Klausel gibt es keine Primärschlüsselfelder. In der Tabelle gibt es einen zusammengesetzten Schlüssel, der aus zwei Primärschlüsseln besteht. Die Tabellenfelder sind transid (Primärschlüssel), item1 (Primärschlüssel), value1, value2, value3 und value4. Ich muss die Tabelle nur anhand dieser Bedingungen durchsuchen. Aber das braucht zu viel Zeit. Ich bin neu in ABAP. Bitte hilf mir diesen Code zu optimieren.

Answer 1

Obwohl Sie nicht genügend Informationen zur Verfügung haben, um völlig sicher zu sein, was das eigentliche Problem ist, könnte man annehmen, dass das Leistungsproblem die Tatsache ist, dass Sie Nicht-Schlüsselfelder im Zustand der Schleife verwenden.

LOOP AT lt_tab INTO ls_tab 
    WHERE ((value1 EQ lv_id1) AND 
    (value2 LE lv_id2 AND value3 GE lv_id3)). 

Sie könnten einen sekundären sortierten Schlüssel für den Tabellentyp der Variablen lt_tab definieren, die die Felder value1, value2 und value3 enthalten würde.

Sehen Sie sich das folgende Beispiel an.

REPORT zzy. 

CLASS lcl_main DEFINITION FINAL CREATE PRIVATE. 
    PUBLIC SECTION. 
    CLASS-METHODS: 
     class_constructor, 
     main. 
    PRIVATE SECTION. 
    TYPES: BEGIN OF t_record, 
     transid TYPE sy-index, 
     item1 TYPE char20, 
     value1 TYPE p LENGTH 7 DECIMALS 2, 
     value2 TYPE p LENGTH 7 DECIMALS 2, 
     value3 TYPE p LENGTH 7 DECIMALS 2, 
     value4 TYPE p LENGTH 7 DECIMALS 2, 
    END OF t_record, 
    tt_record TYPE STANDARD TABLE OF t_record WITH NON-UNIQUE KEY transid item1. 
* tt_record TYPE STANDARD TABLE OF t_record WITH NON-UNIQUE KEY transid item1 WITH UNIQUE SORTED KEY sec_key COMPONENTS value1 value2 value3. 
    CONSTANTS: 
     mc_value1 TYPE p LENGTH 7 DECIMALS 2 VALUE '100.00', 
     mc_value2 TYPE p LENGTH 7 DECIMALS 2 VALUE '150.00', 
     mc_value3 TYPE p LENGTH 7 DECIMALS 2 VALUE '10.0'. 
    CLASS-DATA: 
     mt_record TYPE tt_record. 
ENDCLASS. 

CLASS lcl_main IMPLEMENTATION. 
    METHOD class_constructor. 
    DO 2000000 TIMES. 
     INSERT VALUE t_record(transid = sy-index item1 = |Item{ sy-index }| value1 = sy-index value2 = sy-index/2 value3 = sy-index/4 value4 = 0) 
     INTO TABLE mt_record. 
    ENDDO. 
    ENDMETHOD. 

    METHOD main. 
    DATA: 
     l_start TYPE timestampl, 
     l_end TYPE timestampl, 
     l_diff LIKE l_start. 
    GET TIME STAMP FIELD l_start. 
    LOOP AT mt_record INTO DATA(ls_record) "USING KEY sec_key 
     WHERE value1 = mc_value1 AND value2 >= mc_value2 AND value3 <= mc_value3. 

     ASSERT 1 = 1. 

    ENDLOOP. 
    GET TIME STAMP FIELD l_end. 
    l_diff = l_end - l_start. 

    WRITE:/l_diff. 
    ENDMETHOD. 
ENDCLASS. 

START-OF-SELECTION. 
    lcl_main=>main(). 

Wenn der Tabellentyp tt_record in der folgenden Art und Weise definiert ist

tt_record TYPE STANDARD TABLE OF t_record WITH NON-UNIQUE KEY transid item1. 

dann die Laufzeit der Schleife auf meinem SAP-System unterscheidet sich von 0.156 zu 0.266 Sekunden.

Wenn Sie es jedoch definieren, wie

folgt

tt_record TYPE STANDARD TABLE OF t_record WITH NON-UNIQUE KEY transid item1 WITH UNIQUE SORTED KEY sec_key COMPONENTS value1 value2 value3. 

und die Schleife anpassen, indem Sie den Hinweis Hinzufügen USING KEY sec_key dann die Laufzeit ich jedes Mal bekommen 0.00 ist.

Answer 2

Sie können LOOP AT ... ASSIGNING (<fieldsymbol>) verwenden. Die Zuordnung ist leistungsfähiger als die LOOP AT ... INTO structure. Here einige weitere Informationen.

Answer 3

Wenn Sie viele Daten haben, hilft es nicht, eine Codezeile ein wenig schneller zu machen.

Das Problem besteht wahrscheinlich darin, dass Sie einen vollständigen Tabellenscan durchführen. Sie bearbeiten jede Zeile der Tabelle (bis Sie finden, was Sie suchen)

Für diese Art von Problem, gibt es sortierte Tabellen und Hash-Tabellen:

http://help.sap.com/saphelp_nw70/helpdata/en/fc/eb366d358411d1829f0000e829fbfe/content.htm

Wenn Sie sie verwenden Mit Bedacht muss die Auswahl nur einen Bruchteil der Zeilen in der Tabelle überprüfen, was zu einer viel schnelleren Auswahl führt, abhängig von der Verteilung der Daten in Ihrer Tabelle.

Answer 4

In diesem Fall brauchen wir eine SORTIERTER interne Tabelle statt STANDARD interne Tabelle (Standardverhalten) die Leistung für die Massendaten Fall zu verbessern.

Beispiel der Definition der internen Tabelle

DATA: lt_sorted_data TYPE SORTED TABLE OF TABLENAME WITH NON-UNIQUE KEY MTART. 

Nun, in Ihrem Fall, da die TABELLENNAME ist bereits eine Datenbanktabelle, die bereits einen Primärschlüssel enthält, müssen wir eine andere (lokale) Struktur mit erstellen die gleichen Spalte Listen und über

select * into CORRESPONDING FIELDS OF TABLE lt_sorted_data 

die Daten laden Dann wird es schneller sein, bei log (n) Basis.