topic Re: Read Performance in Application Development and Automation Discussions

Read Performance

Former Member — Sat, 16 Feb 2008 07:05:06 GMT

How can I make the performance of my search better when I Read a table?

Re: Read Performance

Former Member — Sat, 16 Feb 2008 07:28:48 GMT

Hi Biju,

Use BINARY SEARCH in READ

Pre-requisite for using binary search is , u have to sort the internal table for the fields used in the where condition

SORT ITAB BY MATNR.

READ TABLE ITAB WITH KEY MATNR = V_MATNR BINARY SEARCH.

Re: Read Performance

Former Member — Sat, 16 Feb 2008 07:31:41 GMT

By defalut, read command on internal table will read it sequentially. The binary search algorithm helps faster search of a value in an internal table. But you must sort it before use binary search. Binary search repeatedly divides the search interval in half. If the value to be searched is less than the item in the middle of the interval, the search is narrowed to the lower half, otherwise the search is narrowed to the upper half.

Re: Read Performance

Former Member — Sat, 16 Feb 2008 19:01:51 GMT

Or use Sorted or Hashed tables.

Rob

Re: Read Performance

Former Member — Mon, 18 Feb 2008 08:49:54 GMT

In new developments you should use sorted or hashed tables.

Sorted tables are always sorted and can use binary search automatically.

Standard tables must search sequentially by default, because it is not guaranteed that the table is sorted. Therefore you must sort and use binary search manually.

Siegfried

Re: Read Performance

Former Member — Mon, 18 Feb 2008 17:38:05 GMT

I tend to re-use internal tables and find that defining them as anything but standard reduces flexibility, so I don't use sorted or hashed.

Rob

Re: Read Performance

Former Member — Tue, 19 Feb 2008 10:09:04 GMT

Rob,

reuse tables in a standard application or in a test program?

I would say that flexibility is highly overestimated. Performance critcial are the really large internal tables, the ones which grows with the processed data. They should not be reused.

There are actually not that many application where a resorting makes sense. A key should be defined carefully. And in new basis releases it will be possible to define secondary keys.

Siegfried

Re: Read Performance

Former Member — Tue, 19 Feb 2008 15:15:32 GMT

I disagree Siegfried. If there is any performance gain to be gotten by using sorted or hashed tables over sorted standard tables, I don't think it's worth the programming price.

We work in a world where requirements change during the development life cycle. Today's sort order may not be tomorrow's. The same table may have to be sorted different ways depending on requirements. The programmer may be mistaken in a way that requires more than one internal table change.

Programmers tend to be highly paid creatures. I don't think it helps to add additional complexity to save microseconds.

If you're interested, see:

[Performance - what will kill you and what will leave you with only a flesh wound|/people/rob.burbank/blog/2006/11/16/performance--what-will-kill-you-and-what-will-leave-you-with-only-a-flesh-wound]

Rob

Re: Read Performance

Former Member — Wed, 20 Feb 2008 15:52:54 GMT

> Today's sort order may not be tomorrow's.

No, I would call it bad design.

Binary search is actually slightly faster than sorted read, but still, the recommendation is to use special tables, because they are much more fault tolerant.

And I do not understand your argument. I can change the sort order of a sorted globally by one coding change. There is nearly no chance to change a sort order

of an existing standard table, because it might be used in dynamic coding.

Siegfried

Re: Read Performance

Former Member — Wed, 20 Feb 2008 15:57:23 GMT

Not bad design - changing requirements.

Rob

Re: Read Performance

Former Member — Wed, 20 Feb 2008 16:20:57 GMT

sounds very theoretical, an internal table has a main access key. But hwo should it happen that this changes to something completely different.

I have never seen that.

It might happen that an additional key field is necessary, but that is no problem for sorted table.

It might happen that other access types become also important. This is sometimes the case. But then in most cases, both access paths are at the same

time important. It does not make sense to resort the table (a sort is costly it needs many binary searchs to justify the cost). Here oinly secondary keys really help.

Up to that release, table copies of different order are necessary.

Siegfried

Re: Read Performance

ThomasZloch — Wed, 20 Feb 2008 16:37:19 GMT

nice to see two titans butt heads over an interesting topic! (although the question is answered and points awarded to the errr best answers...)

I have one example in favor of SORTED table from my practice. In (quite rare) cases I have to work with nested loops over two internal tables, which are obviously linked by a key of some sort. In the inner loop, I cannot give the addition BINARY SEARCH for the LOOP statement, so I definetely want this inner table to be a SORTED one, so only those records will be scanned, that match the WHERE condition in the loop statement, without a full table scan.

I rarely use HASHED tables though, if at all.

Cheers

Thomas

Edit: this applies of course not only to nested loops, but whenever you access an internal table not by READ TABLE ... BINARY SEARCH but by LOOP AT ... WHERE ...

Re: Read Performance

Former Member — Wed, 20 Feb 2008 17:28:56 GMT

Changing requirements is maybe a bad example, but many times I get an internal table, sort it one way, do some processing, sort it a different way, do some more processing, etc. I find a standard table easy to use for this (ie. more flexible - which was my point).

Heehee - it was me that suggested sorted/hashed tables.

Rob

Edited by: Rob Burbank on Feb 20, 2008 12:39 PM

Re: Read Performance

Former Member — Wed, 20 Feb 2008 17:56:13 GMT

@Thomas

thanks

There is actually also for the LOOP AT WHERE a performant solution with standard tables, see last section of

Measurements on internal tables: Reads and Loops:

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

If the exit condition is missing then it is not really faster!

I recommend sorted tables, because 90% of the programmer don't know that LOOP at WHERE with standard tables is not optimized.

The problem of non-scalable programs is a serious one. But here in the forum it is rarely discussed. And my 2 blogs about a method to identify such problems

Nonlinearity Check

/people/siegfried.boes/blog/2008/01/24/nonlinearity-check-using-the-zse30compare

Z_SE30_COMPARE

/people/siegfried.boes/blog/2008/01/15/a-tool-to-compare-runtime-measurements-zse30compare

are not really popular.

Hashed tables actually make sense when GUIDs are used. They are faster only for very large tables.

@Rob

that's why I asked whether you talk about application programs or test programs. In performance critical program

you should think about resorting your tables. I have not seen many programs where a table is for while exclusively accessed in one type and then exclusively in another.

I have seen more often

loop at itab1

sort itab2

read itab2 ... binary search

endloop.

Siegfried

Re: Read Performance

Former Member — Wed, 20 Feb 2008 18:02:55 GMT

Well, I've never seen a program where a binary search on a sorted standard table wasn't fast enough.

Rob

Re: Read Performance

ThomasZloch — Wed, 20 Feb 2008 21:07:11 GMT

Hi Siegfried,

I've studied and like your blogs about ST05 and SE30, will check out these other ones as well.

>But here in the forum it is rarely discussed

Unfortunately so. Well, I have my whitelist of people who keep posting advanced content...guess who's on it.

Greetings

Thomas