Improve Performance (SCI: sequential search LOOP AT ... WHERE ...)

[Former Member]

I loop over an internal table like this:

LOOP AT me->objects INTO lwa_object WHERE trkorr IN ira_trkorr[].
...
ENDLOOP.

The warning I get from the Code Inspector is:

<i>When using the current statement for an internal table of the STANDARD type, the system runs a sequential search. In some cases, the entire table is read (internally). This has a considerable negative effect on performance if the table contains numerous entries.</i>

The me->objects is defined as a sorted table type with (almost) all the fields as key (UNIQUE). The table type is a sorted table with (almost) all the fields as key (UNIQUE).

The table contains transports and the objects in those transports. So multiple lines for one transport.

Like:

Transport Object

1..............A

1..............B

2..............A

2..............B

3..............A

4..............A

4..............B

I need to only check certain selected transport numbers. For example the user has selected transport number 1 and 4. ira_trkorr[] is a range table with the selected transports.

What I can do to solve this performance warning is to first loop over the me->objects table and append the selected lines into a temporary internal table. Then the above loop can be done on the second table... But that would not improve performance. I think it would even be worse.

And finally, my question: <b>Is there a better solution for this</b>?

Message was edited by:

Edwin Vleeshouwers

Added: Table type is SORTED (Unique key)

[h_senden2]

What you can do is sort the table on trcorr before the loop statement,

or use a sorted internal table.

regards,

Hans

Please reward all helpful answers !!!!!

[Former Member]

Nah, it's already sorted...

The me->objects is defined as a internal table based on a table type. The table type is a sorted table with (almost) all the fields as key (UNIQUE).

The TRKORR field is leading. Still, the LOOP AT... WHERE... does give this warning.

[Former Member]

Hi Edwin ,

Did you try the paralel cursor method, you can make the range table as another table and i think you can use paralel cursor there, or you can make your range table as a hashed table, can access it with key (read table ..) .

Hope this helps,

Caglar

[Former Member]

Sometimes the answer can be so easy (hits head)!

Thanks. I will check this, but of course, instead of using the WHERE, even a simple nested loop may be better and easier on the system. And the blog about parallel cursor method is also very helpful in improving the performance.

I'll first check the solution and will then post back the result.

[Former Member]

Yes, this parallel cursor method solved the problem.

Thanks very much!

PS. Points have been awarded.