This year (2026), at a BW/4HANA customer: brand-new transformation routines in ABAP, cleanly formatted, modern syntax in many places. And right in the middle of it, a READ TABLE ... BINARY SEARCH. Written by a developer who was so young that BINARY SEARCH was already outdated when he was born. When asked why, the answer was the one I have been hearing for twenty years: "It's the fastest way to do a READ. That's how I learned it from my colleagues."
The statement was correct until 1998. Since then, ABAP has stepped up twice. Anyone who writes BINARY SEARCH from scratch today buys the performance of back then at the price of a maintenance risk that they would get for free with sorted and hashed tables.
This article explains where the statement comes from, why it is dangerous, and what belongs in its place.
Where BINARY SEARCH comes from
In classic R/3 ABAP, there was only the standard table. A READ TABLE itab WITH KEY ... searches a standard table linearly, row by row, from top to bottom. With ten entries, it doesn't matter. With a material table of 200,000 rows, it becomes a noticeable problem, especially in loops, where the READ is executed once per iteration.
Binary search solves the problem. If you sort a standard table once by the search key, you can then read it afterwards with the BINARY SEARCH addition. Instead of running linearly through all rows (O(n)), the runtime halves the search range at each step (O(log n)). 200,000 comparisons become about 18. The classic pattern looks like this:
DATA lt_mat TYPE STANDARD TABLE OF ty_material.
SORT lt_mat BY matnr.
READ TABLE lt_mat INTO ls_mat
WITH KEY matnr = lv_matnr
BINARY SEARCH.
IF sy-subrc <> 0.
ls_mat-matnr = lv_matnr.
INSERT ls_mat INTO lt_mat INDEX sy-tabix.
ENDIF.
That was clean craftsmanship for its time. There simply was no better option. Whoever wanted performance sorted themselves and searched binarily.
With Release 4.0, that is, the end of the nineties, the sorted and the hashed table were added. This made the manual construction technically obsolete - from then on, the runtime could take over what previously had been manual work. Around ABAP 7.02 (kernel roughly 2010/2011), the secondary table keys were added on top, with which even a standard table can be given a fast access path without changing its type. This is perfect for refactoring old code. So the tool for the right solution has been ready and waiting for over two decades. But BINARY SEARCH still has the reputation of being the fastest.
What is dangerous about BINARY SEARCH
The problem is the invisible precondition, which often stands far ahead of the READ in the code and is not visible at the read location. And it is also not apparent whether someone, between the SORT and the READ, may have sneaked another record into the internal table.
Binary search works exclusively on a table that is sorted by exactly the fields from the WITH KEY, in precisely that order. If this condition is violated, the runtime still searches binarily - on unsorted data. The result is then simply wrong. sy-subrc may report 4 even though the record is in the table. Or it may report 0 and point to the wrong row. No dump, no syntax error, no warning. The report runs through, the transformation runs through, and somewhere further down the line the numbers are off.
That is what makes the statement so insidious. Correctness depends on a SORT that often sits many rows earlier, sometimes in another method, sometimes generated. Between the sorting and the access lies room for exactly the errors that happen in real projects:
- Someone later adds a second search field and adjusts the
WITH KEY, but forgets theSORT. - Someone inserts data without preserving the sort order.
- Someone re-sorts the table in between for an output by a different field - and thereby destroys the later binary READ.
- Someone copies only the READ block into a new method, in which the table arrives unsorted or sorted differently.
- Someone is not sure whether the table is still sorted, and sorts it once more just to be safe. - This is extremely slow.
The decisive SORT is a separate statement in another place, and the dependency is invisible. Precisely in transformation routines, this meets the worst conditions: large data volumes, generated code around it, many hands in the same module over the years. Finding an accidentally destroyed BINARY READ in such an environment costs days - if it is noticed at all and does not just lead to quietly wrong results.
On top of that comes the manual labor. Every insert operation must preserve the sorting itself, every new access path needs a new SORT. That is maintenance effort that the developer performs manually and can get wrong manually.
Errors caused by a faulty READ ... BINARY SEARCH are very hard to find. This is because it only ever produces follow-on errors.
The alternatives
The solution is to leave the sorting to the runtime instead of managing it by hand. Three ways, depending on the access pattern.
Sorted table - Whoever keeps the table sorted anyway and reads via a key declares it as a SORTED TABLE. The runtime maintains the sorting automatically on every INSERT, and a READ ... WITH KEY over the table key uses binary search of its own accord. The same algorithm, the same complexity, without SORT, without the BINARY SEARCH addition:
DATA lt_mat TYPE SORTED TABLE OF ty_material
WITH UNIQUE KEY matnr.
READ TABLE lt_mat INTO ls_mat
WITH TABLE KEY matnr = lv_matnr.
The precondition here is no longer a matter of trust. It is stated in the type declaration and is enforced by the runtime. An INSERT in the wrong place is not possible, a forgotten SORT cannot happen, because there is no SORT anymore.
Hashed table - If it is about pure key access with a unique key and you do not need index access, the HASHED TABLE is the faster choice. The access runs in constant time (O(1)), independent of the table size. With 200,000 rows, it thereby beats even binary search. This is the point at which the employee's performance argument turns against him: the fastest way to do a key access today is a hashed table, not BINARY SEARCH.
Secondary key - To optimize existing code after the fact, or because you really need the standard table for index access, or because of a predefined interface. Then you give the internal table a secondary, sorted or hashed key and let the runtime maintain it automatically as well:
DATA lt_mat TYPE STANDARD TABLE OF ty_material
WITH NON-UNIQUE SORTED KEY by_matnr
COMPONENTS matnr.
READ TABLE lt_mat INTO ls_mat
WITH KEY by_matnr COMPONENTS matnr = lv_matnr.
The table remains a standard table with all index operations. The read access via by_matnr still runs binary-fast, and the guarantee again lies with the runtime.
Whoever values concise syntax reads from sorted and hashed tables with table expressions that derive their access path from the key just the same:
ls_mat = lt_mat[ matnr = lv_matnr ].
If the row does not exist, this throws a catchable exception (CX_SY_ITAB_LINE_NOT_FOUND); with line_exists( ) it can be checked beforehand. The same speed, readable in one line.
Beyond ABAP, by the way, lookups are actually better placed in the HANA database. Either you do a suitable join in ABAP SQL, or you build a CDS view, or - especially for transformation routines - you go to SQLScript in AMDP.
A small performance comparison of BINARY SEARCH
Also important on this topic is that, precisely for many read operations on large data volumes, BINARY SEARCH is slower than a READ with a complete key on a HASHED TABLE. The measurements were made with approx. 1 million records, and 1 million READs were performed on them. So a typical quadratic-runtime challenge. In absolute numbers, one can say: all of them are very fast. In comparison, the HASHED TABLE wins on the READ, but in return takes longer to build the table. This means that for large internal tables with very many read accesses, the HASHED TABLE pays off.
The code for the test scenario can be found in this gist: https://gist.github.com/captainabap/7fdd15d44d89a7842602759b398db215
Total Records: 1.003.750
Prepare once:
Preparation Time for Binary Search: 185799 µs
Preparation Time for Sorted Table: 208761 µs
Preparation Time for Hashed Table: 251505 µs
Do 1.000.000 times:
Binary Search Time: 197275 µs
Sorted Table Search Time: 194348 µs
Hashed Table Search Time: 118129 µs
Conclusion
BINARY SEARCH is a dinosaur from the Stone Age of ABAP. That era ended with Release 4.0. Whoever writes the statement into new code today gets the speed of a sorted table and adds on top a maintenance and correctness risk that a sorted table does not have.
To this day, BINARY SEARCH is not marked as obsolete. It is even still allowed in ABAP Cloud, see SAP documentation. There is merely the note "Instead of using the addition BINARY SEARCH, it is recommended that work is done either with sorted tables or with sorted secondary table keys."
The "fastest READ" argument is nonsense. A sorted table is exactly as fast, a hashed table is faster, and both enforce the precondition that BINARY SEARCH leaves to the developer. The only remaining reason for the statement is habit and ignorance.
Recommendation for practice: In new code, BINARY SEARCH has no place. Align the table type with the access pattern - sorted for key and index access, hashed for pure key access, secondary key when the standard table must remain. In old code, the cleanup pays off wherever sorting and read access lie far apart or the table is filled from several places. That is exactly where the silent error lurks.
