How to optimize code and Improve performance

[Former Member]

Is there any way to improve the performance and optimize the coding.

SELECT mblnr mjahr zeile mat_kdauf mat_kdpos matnr kdauf kdpos menge
       FROM mseg INTO CORRESPONDING FIELDS OF TABLE imseg
         FOR ALL ENTRIES IN itab
           WHERE bwart IN ('309', '311', '315', '413', '411', '412')
             AND xauto EQ 'X'
             AND matnr EQ itab-matnr
             AND mat_kdauf EQ itab-vbeln
             AND mat_kdpos EQ itab-posnr.
  ENDIF.
  SORT imseg BY kdauf kdpos matnr .
  LOOP AT itab.
    LOOP AT imseg WHERE kdauf = itab-vbeln AND
                        kdpos = itab-posnr. "

      itab-trfr_stk =  itab-trfr_stk + imseg-menge.
    ENDLOOP.
    itab-balqty = itab-kwmeng - ( itab-rfmng + itab-kalab + itab-trfr_stk ).
    MODIFY itab ."TRANSPORTING trfr_stk balqty itab.
  ENDLOOP.

Moderator message - Please see the thread at the top of this forum: . You must show some evidence that there is a performance problem and that you have put in some effort to find where that problem is.}

Edited by: Rob Burbank on Apr 20, 2009 9:33 AM

[Former Member]

Hi,

Few steps might be useful:

1) sort itab on matnr, vebln and posnr and remove adjacent duplicates

2) remove into corresponding fields

3) Instead of loop at itab use loop at itab assigning <fs_itab>, <fs_itab> is field-symbol of type itab, this would help in avoiding modify statment.

4) you can use aggregated function SUM in the query itself.

Regards,

Kritesh Shah

[former_member194613]

The inner loop MUST use a BINARY SEARCH everything else is of much lower importance.

USE a sorted table for imseg

Or check

Measurements on internal tables: Reads and Loops:

/people/siegfried.boes/blog/2007/09/12/runtimes-of-reads-and-loops-on-internal-tables

section 3 a workaround for standard tables !

Siegfried

[Former Member]

1.Try to provide werks in the MSEG ''SELECT".

2.Assuming itab deleted adjacent duplicates on vbeln,posnr.

LOOP table imseg instead ,try to Use AT END OF posnr...look for other logic (READ itab within ENDAT).

Cheers

[Former Member]

Instead of two loops use read statement.

LOOP AT itab.

 Read table IMSEG with key kdauf = itab-vbeln AND kdpos = itab-posnr Binary Search. 
 If sy-subrc = 0.
      itab-trfr_stk =  itab-trfr_stk + imseg-menge.
 ENDIF.

    itab-balqty = itab-kwmeng - ( itab-rfmng + itab-kalab + itab-trfr_stk ).
    MODIFY itab ."TRANSPORTING trfr_stk balqty itab.
  ENDLOOP.

Regards,

Gurpreet

[Former Member]

Instead of using loop inside the loop, use read statement as follows

loop at itab.

read table itab2 with key field = itab-field.

if sy-subrc = 0.

processing.

endif.

endloop.

If it is really necessary to use loop with is the loop then use the following code for better performence.

Sort itab2

loop at itab1.

read table itab2 with key fld1 = itab1-fld1 fld2 = itab1-fld2 binary search.

if sy-subrc = 0.

lv_tabix = sy-tabix

loop at itab2 into <fs> from lv_tabix.

processing.

endloop.

endif.

endloop.

[Former Member]

Use parallel cursor technique for your second loop

data: l_tabix type sy-tabix.
  sort itab by <key field>
  sort imseg by kdauf kdpos matnr.
  loop at itab.
    Read table imseg WHERE kdauf = itab-vbeln AND kdpos = itab-posnr binary search.
    l_tabix = sy-tabix.
    loop at imseg index l_tabix.
      if ( kdauf = itab-vbeln AND kdpos = itab-posnr ).
        l_tabix = sy-tabix.
        itab-balqty = itab-kwmeng - ( itab-rfmng + itab-kalab + itab-trfr_stk ).
        MODIFY itab index l_tabix TRANSPORTING trfr_stk balqty itab.
      else.
      exit.
    endif.
  endloop.
endloop.

Regards,

Lalit Mohan Gupta.

[former_member194613]

How often are the same points repeated aagin and again !!!!

The read reads only one line, it can not replace a loop

Forget the parallel cursor

The way to go is a Sorted table

Is there anybody, who understands that ??????????????????????

Siegfried

[ThomasZloch]

u2665Yesu2665

[Former Member]

In parallel cursor the loop is not replaced by read.

Read is just taken to get the index.

If you see the code both the loop still exist, its just the way i use it is changed.

Regards,

Lalit Mohan Gupta.

[ThomasZloch]

But this parallel cursor approach is unnecessarily complex and thus obsolete, since sorted tables (defined as SORTED, not sorted via SORT!) can be used for the inner loop (there is an implicit binary search when the table key is used in the where-conditions)

Thomas

[former_member194613]

yes, parallel cursor works differently

BUT, if both tables have lines which are not in the other table, then it becomes much more complex than your solution.

And this is completely unnecessary, use the sorted table, then only the inner table must be sorted.

With parallel cursor both must be sorted. The additional cost for the second sort is often misunderstood as the advantage of the parallel cursor.

Use parallel cursor if you process several ten thousand rows, then it is worth to invest to time into

the development.

Otherwise, the sorted table is the recommended solution!

Siegfried

[Former Member]

Avoid INTO CORRESPONDING FIELDS.

[former_member194613]

> Avoid INTO CORRESPONDING FIELDS.

reason: because it was repeated 1000-times.

Was it ever tested ... not by the people who repeat it.

[Former Member]

Enough.

Rob