LOOP within a SUBROUTINE/METHOD/FM within a LOOP.

[Former Member]

Just a random stupid question. LOOP within a LOOP is somewhat a NO-NO and must be avoided 'whenever' possible. So does the title above applies to the rule ?!

Visual:

LOOP.

.....

PERFORM subroutine.

.....

ENDLOOP.

FORM subroutine.

.......

LOOP.

........

ENDLOOP.

........

ENDFORM.

[SuhaSaha]

Hello Jay,

The code you've posted is a dirty trick to hide your nested LOOPs.

LOOP within a LOOP is somewhat a NO-NO and must be avoided 'whenever' possible

I have encountered 100's of scenarios where nested LOOPs can't be avoided. Nested LOOPs can be optimised by:

1. Using SORTED TABLEs in conjunction with LOOP...WHERE. This is less error-prone & my favorite.

2. Using the "outdated" parallel cursor method. Yyou can be in a mess if the inner LOOP is not EXITed using proper conditions.

Hope this helps.

BR,

Suhas

[Former Member]

Hahaha. Well yeah it's a dirty trick. Can you explain further the SORTED TABLE and LOOP...WHERE solution?! Also, is using AT a good idea like the one below ?! cause i kind of don't like the fact that some field values turned ***** when using AT statements specially when I need it to read the inside table.:

from

-

---

LOOP itab1. <--- header

LOOP itab2. <--- item

...

ENDLOOP.

ENDLOOP.

to

---

LOOP itab2.

AT NEW field.

READ TABLE itab1.

ENDAT

....

ENDLOOP.

[yuri_ziryukin]

Hello Jay,

Hermann has explained you above the theory, now to the practice answering your question:

LOOP itab1. <--- header

LOOP itab2. <--- item

...

ENDLOOP.

ENDLOOP.

The optimized version will look like this:

1. define itab2 as a SORTED table with key HEADER_NO, ITEM_NO.

The first loop will stay the same, the second loop will change a little:

LOOP itab1. <--- header

LOOP itab2 WHERE header_no = itab1-header_no. <--- item

...

ENDLOOP.

ENDLOOP.

Due to the fact that the itab2 is a sorted table, SAP kernel is using an optimized algorythm to access the itab2, so not all of the lines of the itab2 are scanned. In this way you avoid quadratic scaling behaviour.

Regards,

Yuri

[Former Member]

Hi Yuri,

Does the key in the sorted table has to be unique?

[yuri_ziryukin]

Hi Yuri,
> 
> 
> Does the key in the sorted table has to be unique?

For the loop statement it doesn't matter.

[HermannGahm]

Hi Jay,

in your coding the inner loop is still inside the outer one, no matter how much modularization units you

put in between.

As Suhas said the goal is not to avoid loops in loops but to avoid quadratic (or worse) run time behaviour.

In generall we do not want to process all rows of an inner loop for each line of the outer one ( n * n = On²).

The inner loop shall be an optimized one with e.g. a logarithmic ( = O log(n)) or constant ( = O (1)) run time

behaviour so that we don't end up with n * n but with something better: n * log n or n * 1.

The general rule "nested loops are bad" comes from the fact that with nested loops there is a high probaility

of quadratic run time behaviour if the inner loops are not optimized ones. Nested loops can sometimes (often) not

be avoided, but they can be optimized (usually)

Kind regards,

Hermann

[Former Member]

and be aware, that many LOOP in LOOP are completely o.k., as one of the LOOPs checks only a number of options, cases or whatever, so the scaling is N*c and c fixed.

The SORTED table is no trick, it is the most recommended out of the options, optimize a basis of BINARY SEARCH, use hashed table (if key is unique) or parallel cursor (complcated).

If you task is a

LOOP and corresponding LOOP at WHERE then also think about whether you can ge rid of the form, it is an overhead if called extremely often.

Siegfried

[Former Member]

Hi Jay,

Instead of using nested loop, you can use the following logic by applying parallel cursor.

It will also improve the performance.

sort itab2 ASCENDING BY field1.

LOOP AT itab1 INTO wa_itab1.
READ TABLE itab2 WITH KEYfield1 = wa_itab1-field BINARY SEARCH TRANSPORTING NO FIELDS.
 IF sy-subrc = 0.
   LOOP AT itab2 INTO wa_itab2 FROM sy-tabix.
    IF wa_itab2-field1 NE wa_fitab1-field.
       EXIT.  "    --->  This logic will minimize the loop passes
    ENDIF.
   ENDLOOP.
 ENDIF.
ENDLOOP.

Thanks,

Suchandra

Edited by: Matt on May 9, 2011 9:08 AM - use tags - it improves readability

[Former Member]

Hi,

Better apply parallel cursor. It will also improve the performance. Ref the below link

http://wiki.sdn.sap.com/wiki/display/Snippets/ABAPCodeforParallelCursor-Loop+Processing

hope it will useful.

Regards,

Dhina..

[ravi_lanjewar]

@Yuri,

Does the key in the sorted table has to be unique?

You can define unique or non-unique key.

@Dhina DMD,

  
Better apply parallel cursor. It will also improve the performance.

Yes, It will improve the performance but it handling loop is over head and complicated exturnal procedure.

Better to used sorted table where it very ease write code simply without any complication work line parallel cursor method internally.

I will recommand to don't use the parallel cursor method and use the sorted table instead of it.

Kind Rgds

Ravi Lanjewar

[Former Member]

Better apply parallel cursor. It will also improve the performance. Ref the below link

http://wiki.sdn.sap.com/wiki/display/Snippets/ABAPCodeforParallelCursor-Loop+Processing

This is not the parallel cursor method!!! The parallel cursor is different, works with 2 loops and a complicated logic on the indexes.

The wiki explains the solution with the sorted standard table, using BINARY SEARCH, LOOP FROM INDEX, EXIT. This is o.k., but cumbersome and also outdated. The sorted table does the same automatically!

The key will be non-unique in most cases, if you define a unique key you can run into trouble if duplicate keys appear.

[Former Member]

tenx