02-16-2008 7:05 AM
How can I make the performance of my search better when I Read a table?
02-16-2008 7:31 AM
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.
02-16-2008 7:28 AM
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.
02-16-2008 7:31 AM
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.
02-16-2008 7:01 PM
02-18-2008 8:49 AM
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
02-18-2008 5:38 PM
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
02-19-2008 10:09 AM
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
02-19-2008 3:15 PM
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
02-20-2008 3:52 PM
> 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
02-20-2008 3:57 PM
02-20-2008 4:20 PM
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
02-20-2008 4:37 PM
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 ...
02-20-2008 5:28 PM
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
02-20-2008 5:56 PM
@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
02-20-2008 6:02 PM
Well, I've never seen a program where a binary search on a sorted standard table wasn't fast enough.
Rob
02-20-2008 9:07 PM
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