Alternate for Loop within Loop for optimization

[Former Member]

Dear friends,

LOOP AT i_po.

LOOP AT i_eban WHERE banfn = i_po-banfn

AND bnfpo = i_po-bnfpo.

i_prpo-matnr = i_eban-matnr.

i_prpo-txz01 = i_eban-txz01.

i_prpo-banfn = i_eban-banfn.

i_prpo-bnfpo = i_eban-bnfpo.

i_prpo-badat = i_eban-badat.

i_prpo-menger = i_eban-menge.

i_prpo-meinsr = i_eban-meins.

i_prpo-ebeln = i_po-ebeln.

i_prpo-ebelp = i_po-ebelp.

i_prpo-bedat = i_po-bedat.

i_prpo-menge = i_po-menge.

i_prpo-lifnr = i_po-lifnr.

APPEND i_prpo.

CLEAR i_prpo.

ENDLOOP.

IF sy-subrc <> 0.

• only PO details

i_prpo-ebeln = i_po-ebeln.

i_prpo-ebelp = i_po-ebelp.

i_prpo-bedat = i_po-bedat.

i_prpo-menge = i_po-menge.

i_prpo-lifnr = i_po-lifnr.

APPEND i_prpo.

CLEAR i_prpo.

ENDIF.

ENDLOOP.

is there a way as 2 how i could remove loop within loop and still get the same o/p..

Please guide me.

Regards,

Essam

[Former Member]

Please see:

[The Performance of Nested Loops|/people/rob.burbank/blog/2006/02/07/performance-of-nested-loops]

Rob

[uwe_schieferstein]

Hello Essam

The blog of Rob is a MUST READ about this topic. Highly recommended.

Regards

Uwe

[Former Member]

Hi pal. Here are some steps that may help you:

- Sort both your internal tables by the main keys that will link them.

- Choose the main table (the straighter course for the data you want), in this case I guess it may be I_PO.

- Loop the main table.

- Move the desired values from the main table to the destiny.

- Read the data on the secondary table using the key fields you sorted before. For that you can use the READ TABLE command. As you sorted the tables you can use the BINARY SEARCH clause, which will make it seek faster.

- Move the desired values from the secondary table to the destiny.

Hope it can help!

[Former Member]

Your coding is a wonderful example for quadratic coding, whcih is a big performance problem.

You must sort only the inner table, and optimize the access by

 
loop
 
  read binary search,
  loop from index, 
  exit if condition is not fulfilled.

   endloop
endloop

See last section of this blog for details:

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

If it helps read the rest of the blog

Use a sorted table as the inner table, then everything works automatically.

It makes no sense to sort the outer table!

Siegfried

[ThomasZloch]

why are you posting your question twice?

I stick to my answer in that first thread, toss out i_po and i_eban, rather select all you need into i_prpo right away using a join select on EKKO, EKPO and EBAN (outer join on EBAN so you get those POs without a requisition as well).

Cure the cause, not the symptoms.

over & out

Thomas

[Former Member]

hi,

Nested Loops - This is one of the fear factors for all the ABAP developers as this consumes lot of program execution time. If the number of entries in the internal tables is huge, then the situation would be too worse. The solution for this is to use parallel cursor method whenever there is a need for Nested Loop.

Program using Normal Nested Loop:

REPORT  ZNORMAL_NESTEDLOOP.

TABLES:
  likp,
  lips.

Data:
  t_likp  type table of likp,
  t_lips  type TABLE OF lips.

data:
  W_RUNTIME1 TYPE I,
  W_RUNTIME2 TYPE I.

START-OF-SELECTION.
select *
  from likp
  into table t_likp.

select *
  from lips
  into table t_lips.

get RUN TIME FIELD w_runtime1.

loop at t_likp into likp.
  loop at t_lips into lips where vbeln eq likp-vbeln.
  endloop.
endloop.

get RUN TIME FIELD w_runtime2.

w_runtime2 = w_runtime2 - w_runtime1.

write w_runtime2.

Nested Loop using Parallel Cursor:

REPORT  zparallel_cursor2.

TABLES:
  likp,
  lips.

DATA:
  t_likp  TYPE TABLE OF likp,
  t_lips  TYPE TABLE OF lips.

DATA:
  w_runtime1 TYPE i,
  w_runtime2 TYPE i,
  w_index LIKE sy-index.

START-OF-SELECTION.
  SELECT *
    FROM likp
    INTO TABLE t_likp.

  SELECT *
    FROM lips
    INTO TABLE t_lips.

  GET RUN TIME FIELD w_runtime1.
  SORT t_likp BY vbeln.
  SORT t_lips BY vbeln.

  LOOP AT t_likp INTO likp.

    LOOP AT t_lips INTO lips FROM w_index.
      IF likp-vbeln NE lips-vbeln.
        w_index = sy-tabix.
        EXIT.
      ENDIF.
    ENDLOOP.
  ENDLOOP.

  GET RUN TIME FIELD w_runtime2.

  w_runtime2 = w_runtime2 - w_runtime1.

  WRITE w_runtime2.

Iteration No | Normal Nested Loop  | Using Parallel Cursor  
1.               | 34,796,147               | 63,829  
2.               | 38,534,583               | 56,894  
3.               |34,103,426                | 50,510  

Hope this helps, Do reward.

Edited by: Runal Singh on Mar 18, 2008 12:39 PM

[Former Member]

> Nested Loops - This is one of the fear factors for all the ABAP developers as this consumes lot of program

> execution time. If the number of entries in the internal tables is huge, then the situation would be too worse.

> The solution for this is to use parallel cursor method whenever there is a need for Nested Loop.

This is incorrect!

A processing with sorted or hashed tables as inner tables is perfectly o.k. and the recommended

solution.

For standard tables you need a workaround as mentioned above (Find starting point with binary search, loop from index,

and stop loop as soon as condition is not fulfilled).

The parallel cursor is in general much to complictated, and actually only slightly faster. People think that is much faster, but they

that this solution requires a sort for both tables. In all other solutions it is not necessary to0 sort the other table.

And Thomas is of course right. If there is a possiblity to select the data in an effective join, then the nested loop should be

avoided. However, there are of course many nested loop tasks which can not be avoided.

Siegfried

[former_member183804]

Hello Essam,

if the data amount for the give sample causes a performance issue, then it is very likey a memory issue too. From the basic logic it seems to do a kind of inner join on 2 internal tables of n and m entries into table with n * m entries.

Depending on the logic afterwards one may consider a redesign of the data structures. For sample to have one structure with 2 tables which have some kind manual link (e.g. a column index with the table index of the other table).

Regards

Klaus