topic Re: performance tuning. in Application Development and Automation Discussions

performance tuning.

Former Member — Wed, 21 Nov 2007 11:46:31 GMT

hi, m an abap fresher. i m working on a performance tuning.can u help me in reducing performance time of this select query.

SELECT ekpo_{ebeln ekpo}ebelp ekes_{etens ekpo}matnr ekpo~meins

ekko_{lifnr ekpo}elikz ekes_{menge ekes}dabmg

INTO TABLE itb_ekpo

FROM ekko INNER JOIN ekpo ON ekko_{ebeln EQ ekpo}ebeln

INNER JOIN ekes ON ekpo_{ebeln EQ ekes}ebeln

AND ekpo_{ebelp EQ ekes}ebelp

FOR ALL entries IN itb_edit_cle

WHERE ekko~lifnr EQ itb_edit_cle-lifnr

AND ekpo~matnr EQ itb_edit_cle-matnr

AND ekpo~werks EQ p_werks

AND ekpo~bstyp EQ 'F'

AND ekpo~loekz EQ ' '

AND ( ( ekpo~elikz EQ ' '

OR ekes~dabmg LE 0

OR ekes~menge LE 0 )

AND ekes~menge GT 0

AND ekes_{dabmg LT ekes}menge )

AND ekes~ebtyp EQ 'AL'.

IF sy-dbcnt GT 0.

SORT itb_ekpo BY matnr lifnr.

ENDIF.

itb_edit_cle is an internal table.should i replace 2 inner joins with a select for all entries. and if so how?

Re: performance tuning.

Former Member — Wed, 21 Nov 2007 11:57:50 GMT

USE FOR ALL ENTRIES INSTEAD OF JOINS

IT WILL IMPROVE THE PERFORMANCE

IF YOU USE JOINS THEN THE DATA BASE CONNECTION WITH THAT TABLES EXIST UP TO THE PROGRAM EXECUTION SO RESULT IN LOAD ON DATABASE

I AM SENDING YOU SOME POINTS BELOW USE THAT POINTS FOR FETURE REFERENCE

Ways of Performance Tuning

1. Selection Criteria

2. Select Statements

• Select Queries

• SQL Interface

• Aggregate Functions

• For all Entries

Select Over more than one Internal table

Selection Criteria

1. Restrict the data to the selection criteria itself, rather than filtering it out using the ABAP code using CHECK statement.

2. Select with selection list.

Points # 1/2

SELECT * FROM SBOOK INTO SBOOK_WA.

CHECK: SBOOK_WA-CARRID = 'LH' AND

SBOOK_WA-CONNID = '0400'.

ENDSELECT.

The above code can be much more optimized by the code written below which avoids CHECK, selects with selection list

SELECT CARRID CONNID FLDATE BOOKID FROM SBOOK INTO TABLE T_SBOOK

WHERE SBOOK_WA-CARRID = 'LH' AND

SBOOK_WA-CONNID = '0400'.

Select Statements Select Queries

1. Avoid nested selects

2. Select all the records in a single shot using into table clause of select statement rather than to use Append statements.

3. When a base table has multiple indices, the where clause should be in the order of the index, either a primary or a secondary index.

4. For testing existence , use Select.. Up to 1 rows statement instead of a Select-Endselect-loop with an Exit.

5. Use Select Single if all primary key fields are supplied in the Where condition .

Point # 1

SELECT * FROM EKKO INTO EKKO_WA.

SELECT * FROM EKAN INTO EKAN_WA

WHERE EBELN = EKKO_WA-EBELN.

ENDSELECT.

The above code can be much more optimized by the code written below.

SELECT P_{F1 P}F2 F_{F3 F}F4 INTO TABLE ITAB

FROM EKKO AS P INNER JOIN EKAN AS F

ON P_{EBELN = F}EBELN.

Note: A simple SELECT loop is a single database access whose result is passed to the ABAP program line by line. Nested SELECT loops mean that the number of accesses in the inner loop is multiplied by the number of accesses in the outer loop. One should therefore use nested SELECT loops only if the selection in the outer loop contains very few lines or the outer loop is a SELECT SINGLE statement.

Point # 2

SELECT * FROM SBOOK INTO SBOOK_WA.

CHECK: SBOOK_WA-CARRID = 'LH' AND

SBOOK_WA-CONNID = '0400'.

ENDSELECT.

The above code can be much more optimized by the code written below which avoids CHECK, selects with selection list and puts the data in one shot using into table

SELECT CARRID CONNID FLDATE BOOKID FROM SBOOK INTO TABLE T_SBOOK

WHERE SBOOK_WA-CARRID = 'LH' AND

SBOOK_WA-CONNID = '0400'.

Point # 3

To choose an index, the optimizer checks the field names specified in the where clause and then uses an index that has the same order of the fields . In certain scenarios, it is advisable to check whether a new index can speed up the performance of a program. This will come handy in programs that access data from the finance tables.

Point # 4

SELECT * FROM SBOOK INTO SBOOK_WA

UP TO 1 ROWS

WHERE CARRID = 'LH'.

ENDSELECT.

The above code is more optimized as compared to the code mentioned below for testing existence of a record.

SELECT * FROM SBOOK INTO SBOOK_WA

WHERE CARRID = 'LH'.

EXIT.

ENDSELECT.

Point # 5

If all primary key fields are supplied in the Where condition you can even use Select Single.

Select Single requires one communication with the database system, whereas Select-Endselect needs two.

Select Statements contd.. SQL Interface

1. Use column updates instead of single-row updates

to update your database tables.

2. For all frequently used Select statements, try to use an index.

3. Using buffered tables improves the performance considerably.

Point # 1

SELECT * FROM SFLIGHT INTO SFLIGHT_WA.

SFLIGHT_WA-SEATSOCC =

SFLIGHT_WA-SEATSOCC - 1.

UPDATE SFLIGHT FROM SFLIGHT_WA.

ENDSELECT.

The above mentioned code can be more optimized by using the following code

UPDATE SFLIGHT

SET SEATSOCC = SEATSOCC - 1.

Point # 2

SELECT * FROM SBOOK CLIENT SPECIFIED INTO SBOOK_WA

WHERE CARRID = 'LH'

AND CONNID = '0400'.

ENDSELECT.

The above mentioned code can be more optimized by using the following code

SELECT * FROM SBOOK CLIENT SPECIFIED INTO SBOOK_WA

WHERE MANDT IN ( SELECT MANDT FROM T000 )

AND CARRID = 'LH'

AND CONNID = '0400'.

ENDSELECT.

Point # 3

Bypassing the buffer increases the network considerably

SELECT SINGLE * FROM T100 INTO T100_WA

BYPASSING BUFFER

WHERE SPRSL = 'D'

AND ARBGB = '00'

AND MSGNR = '999'.

The above mentioned code can be more optimized by using the following code

SELECT SINGLE * FROM T100 INTO T100_WA

WHERE SPRSL = 'D'

AND ARBGB = '00'

AND MSGNR = '999'.

Select Statements contd… Aggregate Functions

• If you want to find the maximum, minimum, sum and average value or the count of a database column, use a select list with aggregate functions instead of computing the aggregates yourself.

Some of the Aggregate functions allowed in SAP are MAX, MIN, AVG, SUM, COUNT, COUNT( * )

Consider the following extract.

Maxno = 0.

Select * from zflight where airln = ‘LF’ and cntry = ‘IN’.

Check zflight-fligh > maxno.

Maxno = zflight-fligh.

Endselect.

The above mentioned code can be much more optimized by using the following code.

Select max( fligh ) from zflight into maxno where airln = ‘LF’ and cntry = ‘IN’.

Select Statements contd…For All Entries

• The for all entries creates a where clause, where all the entries in the driver table are combined with OR. If the number of entries in the driver table is larger than rsdb/max_blocking_factor, several similar SQL statements are executed to limit the length of the WHERE clause.

The plus

• Large amount of data

• Mixing processing and reading of data

• Fast internal reprocessing of data

• Fast

The Minus

• Difficult to program/understand

• Memory could be critical (use FREE or PACKAGE size)

Points to be must considered FOR ALL ENTRIES

• Check that data is present in the driver table

• Sorting the driver table

• Removing duplicates from the driver table

Consider the following piece of extract

Loop at int_cntry.

Select single * from zfligh into int_fligh

where cntry = int_cntry-cntry.

Append int_fligh.

Endloop.

The above mentioned can be more optimized by using the following code.

Sort int_cntry by cntry.

Delete adjacent duplicates from int_cntry.

If NOT int_cntry[] is INITIAL.

Select * from zfligh appending table int_fligh

For all entries in int_cntry

Where cntry = int_cntry-cntry.

Endif.

Select Statements contd… Select Over more than one Internal table

1. Its better to use a views instead of nested Select statements.

2. To read data from several logically connected tables use a join instead of nested Select statements. Joins are preferred only if all the primary key are available in WHERE clause for the tables that are joined. If the primary keys are not provided in join the Joining of tables itself takes time.

3. Instead of using nested Select loops it is often better to use subqueries.

Point # 1

SELECT * FROM DD01L INTO DD01L_WA

WHERE DOMNAME LIKE 'CHAR%'

AND AS4LOCAL = 'A'.

SELECT SINGLE * FROM DD01T INTO DD01T_WA

WHERE DOMNAME = DD01L_WA-DOMNAME

AND AS4LOCAL = 'A'

AND AS4VERS = DD01L_WA-AS4VERS

AND DDLANGUAGE = SY-LANGU.

ENDSELECT.

The above code can be more optimized by extracting all the data from view DD01V_WA

SELECT * FROM DD01V INTO DD01V_WA

WHERE DOMNAME LIKE 'CHAR%'

AND DDLANGUAGE = SY-LANGU.

ENDSELECT

Point # 2

SELECT * FROM EKKO INTO EKKO_WA.

SELECT * FROM EKAN INTO EKAN_WA

WHERE EBELN = EKKO_WA-EBELN.

ENDSELECT.

The above code can be much more optimized by the code written below.

SELECT P_{F1 P}F2 F_{F3 F}F4 INTO TABLE ITAB

FROM EKKO AS P INNER JOIN EKAN AS F

ON P_{EBELN = F}EBELN.

Point # 3

SELECT * FROM SPFLI

INTO TABLE T_SPFLI

WHERE CITYFROM = 'FRANKFURT'

AND CITYTO = 'NEW YORK'.

SELECT * FROM SFLIGHT AS F

INTO SFLIGHT_WA

FOR ALL ENTRIES IN T_SPFLI

WHERE SEATSOCC < F~SEATSMAX

AND CARRID = T_SPFLI-CARRID

AND CONNID = T_SPFLI-CONNID

AND FLDATE BETWEEN '19990101' AND '19990331'.

ENDSELECT.

The above mentioned code can be even more optimized by using subqueries instead of for all entries.

SELECT * FROM SFLIGHT AS F INTO SFLIGHT_WA

WHERE SEATSOCC < F~SEATSMAX

AND EXISTS ( SELECT * FROM SPFLI

WHERE CARRID = F~CARRID

AND CONNID = F~CONNID

AND CITYFROM = 'FRANKFURT'

AND CITYTO = 'NEW YORK' )

AND FLDATE BETWEEN '19990101' AND '19990331'.

ENDSELECT.

1. Table operations should be done using explicit work areas rather than via header lines.

2. Always try to use binary search instead of linear search. But don’t forget to sort your internal table before that.

3. A dynamic key access is slower than a static one, since the key specification must be evaluated at runtime.

4. A binary search using secondary index takes considerably less time.

5. LOOP ... WHERE is faster than LOOP/CHECK because LOOP ... WHERE evaluates the specified condition internally.

6. Modifying selected components using “ MODIFY itab …TRANSPORTING f1 f2.. “ accelerates the task of updating a line of an internal table.

Point # 2

READ TABLE ITAB INTO WA WITH KEY K = 'X‘ BINARY SEARCH.

IS MUCH FASTER THAN USING

READ TABLE ITAB INTO WA WITH KEY K = 'X'.

If TAB has n entries, linear search runs in O( n ) time, whereas binary search takes only O( log2( n ) ).

Point # 3

READ TABLE ITAB INTO WA WITH KEY K = 'X'. IS FASTER THAN USING

READ TABLE ITAB INTO WA WITH KEY (NAME) = 'X'.

Point # 5

LOOP AT ITAB INTO WA WHERE K = 'X'.

" ...

ENDLOOP.

The above code is much faster than using

LOOP AT ITAB INTO WA.

CHECK WA-K = 'X'.

" ...

ENDLOOP.

Point # 6

WA-DATE = SY-DATUM.

MODIFY ITAB FROM WA INDEX 1 TRANSPORTING DATE.

The above code is more optimized as compared to

WA-DATE = SY-DATUM.

MODIFY ITAB FROM WA INDEX 1.

7. Accessing the table entries directly in a "LOOP ... ASSIGNING ..." accelerates the task of updating a set of lines of an internal table considerably

8. If collect semantics is required, it is always better to use to COLLECT rather than READ BINARY and then ADD.

9. "APPEND LINES OF itab1 TO itab2" accelerates the task of appending a table to another table considerably as compared to “ LOOP-APPEND-ENDLOOP.”

10. “DELETE ADJACENT DUPLICATES“ accelerates the task of deleting duplicate entries considerably as compared to “ READ-LOOP-DELETE-ENDLOOP”.

11. "DELETE itab FROM ... TO ..." accelerates the task of deleting a sequence of lines considerably as compared to “ DO -DELETE-ENDDO”.

Point # 7

Modifying selected components only makes the program faster as compared to Modifying all lines completely.

e.g,

LOOP AT ITAB ASSIGNING <WA>.

I = SY-TABIX MOD 2.

IF I = 0.

<WA>-FLAG = 'X'.

ENDIF.

ENDLOOP.

The above code works faster as compared to

LOOP AT ITAB INTO WA.

I = SY-TABIX MOD 2.

IF I = 0.

WA-FLAG = 'X'.

MODIFY ITAB FROM WA.

ENDIF.

ENDLOOP.

Point # 8

LOOP AT ITAB1 INTO WA1.

READ TABLE ITAB2 INTO WA2 WITH KEY K = WA1-K BINARY SEARCH.

IF SY-SUBRC = 0.

ADD: WA1-VAL1 TO WA2-VAL1,

WA1-VAL2 TO WA2-VAL2.

MODIFY ITAB2 FROM WA2 INDEX SY-TABIX TRANSPORTING VAL1 VAL2.

ELSE.

INSERT WA1 INTO ITAB2 INDEX SY-TABIX.

ENDIF.

ENDLOOP.

The above code uses BINARY SEARCH for collect semantics. READ BINARY runs in O( log2(n) ) time. The above piece of code can be more optimized by

LOOP AT ITAB1 INTO WA.

COLLECT WA INTO ITAB2.

ENDLOOP.

SORT ITAB2 BY K.

COLLECT, however, uses a hash algorithm and is therefore independent

of the number of entries (i.e. O(1)) .

Point # 9

APPEND LINES OF ITAB1 TO ITAB2.

This is more optimized as compared to

LOOP AT ITAB1 INTO WA.

APPEND WA TO ITAB2.

ENDLOOP.

Point # 10

DELETE ADJACENT DUPLICATES FROM ITAB COMPARING K.

This is much more optimized as compared to

READ TABLE ITAB INDEX 1 INTO PREV_LINE.

LOOP AT ITAB FROM 2 INTO WA.

IF WA = PREV_LINE.

DELETE ITAB.

ELSE.

PREV_LINE = WA.

ENDIF.

ENDLOOP.

Point # 11

DELETE ITAB FROM 450 TO 550.

This is much more optimized as compared to

DO 101 TIMES.

DELETE ITAB INDEX 450.

ENDDO.

12. Copying internal tables by using “ITAB2[ ] = ITAB1[ ]” as compared to “LOOP-APPEND-ENDLOOP”.

13. Specify the sort key as restrictively as possible to run the program faster.

Point # 12

ITAB2[] = ITAB1[].

This is much more optimized as compared to

REFRESH ITAB2.

LOOP AT ITAB1 INTO WA.

APPEND WA TO ITAB2.

ENDLOOP.

Point # 13

“SORT ITAB BY K.” makes the program runs faster as compared to “SORT ITAB.”

Internal Tables contd…

Hashed and Sorted tables

1. For single read access hashed tables are more optimized as compared to sorted tables.

2. For partial sequential access sorted tables are more optimized as compared to hashed tables

Hashed And Sorted Tables

Point # 1

Consider the following example where HTAB is a hashed table and STAB is a sorted table

DO 250 TIMES.

N = 4 * SY-INDEX.

READ TABLE HTAB INTO WA WITH TABLE KEY K = N.

IF SY-SUBRC = 0.

" ...

ENDIF.

ENDDO.

This runs faster for single read access as compared to the following same code for sorted table

DO 250 TIMES.

N = 4 * SY-INDEX.

READ TABLE STAB INTO WA WITH TABLE KEY K = N.

IF SY-SUBRC = 0.

" ...

ENDIF.

ENDDO.

Point # 2

Similarly for Partial Sequential access the STAB runs faster as compared to HTAB

LOOP AT STAB INTO WA WHERE K = SUBKEY.

" ...

ENDLOOP.

This runs faster as compared to

LOOP AT HTAB INTO WA WHERE K = SUBKEY.

" ...

ENDLOOP.

Re: performance tuning.

Former Member — Wed, 21 Nov 2007 12:24:50 GMT

Hi,

do like this

IF itb_edit_cle[] IS NOT INITIAL.
  SELECT lifnr FROM ekko INTO TABLE git_ekko 
   FOR ALL ENTRIES IN itb_edit_cle
    WHERE lifnr = itb_edit_cle-lifnr.
  IF sy-subrc = 0.
   SELECT ebeln ebelp matnr meins elikz FROM ekpo 
    INTO TABLE git_ekpo 
     FOR ALL ENTRIES IN itb_edit_cle
      WHERE matnr = itb_edit_cle-matnr.
        and ekpo~werks eq p_werks
        and ekpo~bstyp eq 'F'
        and ekpo~loekz eq ' '
        and ekpo~elikz eq ' '.
   IF sy-subrc = 0.
     SELECT etens menge dabmg FROM ekes INTO TABLE git_ekes
       FOR ALL ENTRIES IN git_ekpo
          WHERE ebeln = git_ekpo-ebeln
            AND ebelp = git_ekpo-ebelp
             OR dabmg LE 0
            AND ebtyp EQ 'AL'.
    ENDIF.
  ENDIF.
ENDIF.

sort all internal tables by there key fields

loop through first internal table and use read statements to move to final internal table.

Reward Points if this helps,

Regards,

Satish

Re: performance tuning.

Former Member — Wed, 21 Nov 2007 12:38:53 GMT

Can anybody explain me, how an FOR ALL ENTRIES should improve a join.

A join is a nested loop on the database, and FOR ALL ENTRIES is a nested loop partly in ABAP and in the database.

If the join is optimized, then it must be better than the FOR ALL ENTRIES. Some join do not automatically work correctly, but with suitable indexes and maybe database hints it should be possible to improve them.

Try the join and the FOR ALL ENTRIES and the version below, measure the runtimes (GET RUNTIME FIELD) and execute them 10 times in a loop. Which one is better?

Beware that this condition is a bit hard to handle

AND ( ( ekpo~elikz EQ ' '

OR ekes~dabmg LE 0

OR ekes~menge LE 0 )

Siegfried

Re: performance tuning.

former_member190178 — Wed, 21 Nov 2007 12:59:34 GMT

Siegfried Boes: You have said very genuine points.

For all entries is never never going to give you the results in fast way. I am also suffering with this and I have noticed that for all entries will be ok if that particular

internal table has very less data other wise this will take a good amout of time.

Join is not at all a bad deal.

Re: performance tuning.

Former Member — Wed, 21 Nov 2007 14:38:17 GMT

Actually, the SELECT looks pretty good. You have at least two secondary index fields in the WHERE (lifnr and matrnr), so you'd think it would be ok. I wonder if the database is getting confused and not picking the correct index. Can you please run an SQL performance trace (ST05) on this statement and then look at the EXPLAIN to see if it is using an index?

Rob

Re: performance tuning.

Former Member — Wed, 21 Nov 2007 18:04:52 GMT

Try using this code.

TYPES: BEGIN OF ty_ekpo,
         ebeln TYPE ekpo-ebeln,
         ebelp TYPE ekpo-ebelp,
         matnr TYPE ekpo-matnr,
         meins TYPE ekpo-meins,
         elikz TYPE ekpo-elikz,
       END OF ty_ekpo,

       BEGIN OF ty_ekko,
         ebeln TYPE ekko-ebeln,
         lifnr TYPE ekko-lifnr,
       END OF ty_ekko,

       BEGIN OF ty_ekes,
         ebeln TYPE ekes-ebeln,
         ebelp TYPE ekes-ebelp,
         etens TYPE ekes-etens,
         menge TYPE ekes-menge,
         dabmg TYPE ekes-dabmg,
       END OF ty_ekes,

       BEGIN OF ty_ekpo_final,
         ebeln TYPE ekpo-ebeln,
         ebelp TYPE ekpo-ebelp,
         etens TYPE ekes-etens,
         matnr TYPE ekpo-matnr,
         meins TYPE ekpo-meins,
         lifnr TYPE ekko-lifnr,
         elikz TYPE ekpo-elikz,
         menge TYPE ekes-menge,
         dabmg TYPE ekes-dabmg,
       END OF ty_ekpo_final.


DATA: w_ekpo           TYPE          ty_ekpo             ,
      w_ekes           TYPE          ty_ekes             ,
      w_ekko           TYPE          ty_ekko             ,
      w_edit_cle       LIKE          itb_edit_cle        ,
      w_ekpo_final     TYPE          ty_ekpo_final       ,

      itb_edit_cle_tmp LIKE TABLE OF itb_edit_cle        ,
      t_ekpo           TYPE SORTED TABLE OF ty_ekpo
        WITH NON-UNIQUE KEY ebeln matnr                  ,
      t_ekpo_tmp       TYPE        TABLE OF ty_ekpo      ,
      t_ekes           TYPE SORTED TABLE OF ty_ekes
        WITH NON-UNIQUE KEY ebeln ebelp                  ,
      t_ekko           TYPE SORTED TABLE OF ty_ekko
        WITH NON-UNIQUE KEY lifnr                        ,
      itb_ekpo         TYPE        TABLE OF ty_ekpo_final.


REFRESH itb_ekpo.

IF NOT itb_edit_cle[] IS INITIAL.

  itb_edit_cle_tmp[] = itb_edit_cle[].
  SORT itb_edit_cle_tmp BY matnr.
  DELETE ADJACENT DUPLICATES FROM itb_edit_cle_tmp COMPARING matnr.

  SELECT ebeln
         ebelp
         matnr
         meins
         elikz
    FROM ekpo
    INTO TABLE t_ekpo
    FOR ALL ENTRIES IN itb_edit_cle_tmp
    WHERE matnr EQ itb_edit_cle_tmp-matnr
    AND   werks EQ p_werks
    AND   bstyp EQ 'F'
    AND   loekz EQ space.

  IF sy-subrc EQ 0.

    t_ekpo_tmp[] = t_ekpo[].

    SORT t_ekpo_tmp BY ebeln ebelp.

    SELECT ebeln
           ebelp
           etens
           menge
           dabmg
      FROM ekes
      INTO TABLE t_ekes
      FOR ALL ENTRIES IN t_ekpo_tmp
      WHERE ebeln EQ t_ekpo_tmp-ebeln
      AND   ebelp EQ t_ekpo_tmp-ebelp
      AND   ebtyp EQ 'AL'.


    DELETE ADJACENT DUPLICATES FROM t_ekpo_tmp COMPARING ebeln.

    SELECT ebeln
           lifnr
      FROM ekko
      INTO TABLE t_ekko
      FOR ALL ENTRIES IN t_ekpo_tmp
      WHERE ebeln EQ t_ekpo_tmp-ebeln.

  ENDIF.


  LOOP AT itb_edit_cle INTO w_edit_cle.

    READ TABLE t_ekko INTO w_ekko WITH KEY lifnr = w_edit_cle-lifnr
                                           TRANSPORTING
                                             ebeln.

    CHECK sy-subrc EQ 0.

    LOOP AT t_ekpo INTO w_ekpo WHERE ebeln EQ w_ekko-ebeln
                               AND   matnr EQ w_edit_cle-matnr.

      LOOP AT t_ekes INTO w_ekes WHERE ebeln EQ w_ekpo-ebeln
                                 AND   ebelp EQ w_ekpo-ebelp.


        IF ( ( w_ekpo-elikz EQ space
        OR     w_ekes-dabmg LE 0
        OR     w_ekes-menge LE 0 )
        AND    w_ekes-menge GT 0
        AND    w_ekes-dabmg LT w_ekes-menge ).

          w_ekpo_final-ebeln = w_ekpo-ebeln          .
          w_ekpo_final-ebelp = w_ekpo-ebelp          .
          w_ekpo_final-etens = w_ekes-etens          .
          w_ekpo_final-matnr = w_ekpo-matnr          .
          w_ekpo_final-meins = w_ekpo-meins          .
          w_ekpo_final-lifnr = w_edit_cle-lifnr      .
          w_ekpo_final-elikz = w_ekpo-elikz          .
          w_ekpo_final-menge = w_ekes-menge          .
          w_ekpo_final-dabmg = w_ekes-dabmg          .
          APPEND w_ekpo_final TO itb_ekpo.
          CLEAR  w_ekpo_final.

        ENDIF.

      ENDLOOP.

    ENDLOOP.

  ENDLOOP.

ENDIF.

Re: performance tuning.

Former Member — Wed, 21 Nov 2007 18:23:27 GMT

Siegfried Boes,

We write SQL queries using ABAP statements. The database interpreter converts this ABAP SQL to your database specific SQL. The database optimizer makes sure that the translated query is optimum. When you use JOINS, you rely on your database optimizer to do a good job. If it does, your query should run faster than the FOR ALL ENTRIES option. However this is not always the case. When the database optimizer does not do a good job the query will take a long time. The performance of the database optimizer is difficult to predict because it would perform differently for different queries.

When you use FOR ALL ENTRIES you are making sure that the individual SELECT statements are written correctly. The probability that the database optimizer would mess up individual SELECT statements is far less. Even though the FOR ALL ENTRIES option involves looping, you retain more control over your queries as opposed to surrendering it to the database optimizer.

I agree with you that if the database optimizer does a good job a JOIN would perform better but if you want to establish some sort of coding standards for your team, you are better off suggesting FOR ALL ENTRIES as compared to JOINS as in the case of FOR ALL ENTRIES the performance is reasonably good and the only reason there would be a performance issue is if the person writing the code has done a bad job.

Re: performance tuning.

Former Member — Wed, 21 Nov 2007 18:30:43 GMT

Maddu Soni,

If you share with us your code where you have problems with FOR ALL ENTRIES we could help you with it. Just make it a separate post so that you will have points to offer.