SAP Internal tables

An internal table holds multiple rows of a structured type in memory, think of it as a temporary table your program builds and processes. You SELECT database rows into an internal table, then loop, read, sort, filter and aggregate in memory, which is fast and central to nearly every report and interface.

• Standard: general purpose, indexed access.
• Sorted: kept in key order, fast binary-search reads.
• Hashed: keyed, near-constant-time single-row access for large lookups.

The second axis is the key, and it is what actually decides read performance.

A standard table may be declared with a non unique key and is searched linearly unless you sort it and use a binary search. A sorted table is held in key order permanently, so reads by the key or a leading part of it are a binary search automatically, and inserts must respect the order. A hashed table requires a unique key and reads by the full key in roughly constant time however large it gets, and cannot be read by index at all.

The choice follows the access pattern rather than the size. Reading the whole table in order: standard. Repeated reads by a full unique key: hashed. Repeated reads by a partial key, or a need for both keyed access and ordering: sorted.

Secondary keys are the escape hatch when one table genuinely needs two access patterns. A standard table can carry an additional sorted or hashed key that the runtime maintains, so you get keyed reads without giving up index access. They are not free, since the runtime maintains them, and they are far cheaper than building a second copy of the table.

DATA lt_mara TYPE STANDARD TABLE OF mara.
SELECT * FROM mara INTO TABLE @lt_mara UP TO 100 ROWS.

SORT lt_mara BY matnr.
READ TABLE lt_mara INTO DATA(ls) WITH KEY matnr = 'X' BINARY SEARCH.
DELETE lt_mara WHERE mtart = 'ROH'.
DATA(lv_count) = lines( lt_mara ).

A great deal of ABAP you will meet was written before the current syntax existed, so it is worth being able to read both and to write the newer form.

" declaration and inline results
DATA lt_items TYPE SORTED TABLE OF ty_item WITH UNIQUE KEY id.

" read into a field symbol: no copy, and directly modifiable
READ TABLE lt_items ASSIGNING FIELD-SYMBOL(<ls>) WITH TABLE KEY id = lv_id.
IF sy-subrc = 0.
  <ls>-status = 'X'.
ENDIF.

" table expression: shorter, and raises an exception when absent
DATA(ls_item) = lt_items[ id = lv_id ].

" loop over a subset without an IF inside the loop
LOOP AT lt_items ASSIGNING FIELD-SYMBOL(<lx>) WHERE status = 'A'.
ENDLOOP.

" build a new table from an existing one
DATA(lt_open) = VALUE ty_items( FOR ls IN lt_items WHERE ( status = 'A' ) ( ls ) ).

" aggregate without a loop
DATA(lv_total) = REDUCE i( INIT s = 0 FOR ls IN lt_items NEXT s = s + ls-qty ).

Three things to take from that. ASSIGNING avoids copying each row into a work area, which on a wide structure in a long loop is a real saving and also lets you modify the row in place. Table expressions raise an exception rather than setting a return code, so they are cleaner where the row must exist and wrong where it might not. And WHERE on a LOOP lets the runtime skip rows rather than reading every one and testing it.

The obsolete forms to recognise and not to write: a header line on a table declaration, OCCURS clauses, and INTO a work area where ASSIGNING would do.

Choose the table type for the access pattern: hashed/sorted tables make repeated lookups dramatically faster than linear reads on a standard table. For big lookups inside loops, a hashed table (or sorted with binary search) instead of a repeated linear READ is a major optimisation.

The measurement worth internalising is that a linear read is proportional to the number of rows and a keyed read is not. A linear READ inside a loop over another table is therefore proportional to the product of the two, which is fine at a hundred rows each and catastrophic at a hundred thousand. This one pattern accounts for a large share of all ABAP performance problems, and the fix is a change of table type rather than a rewrite.

Two more habits. Select into a table once rather than reading the database inside a loop, because a database round trip per row is far more expensive than anything happening in memory. And free large tables when you are finished with them in a long running program, because memory held is memory nobody else has. See ABAP performance.

• Linear READ in a loop on a big standard table; use sorted/hashed.
• Wrong table type for the access pattern.
• Reading the DB per row instead of into a table once.

Version note: everything above works on any current release. The table expressions, inline declarations, VALUE and REDUCE constructors arrived with the newer ABAP releases, so code intended to run on an older system may need the classic forms, and that is a genuine constraint rather than a style preference. Where you have the choice, the modern form is shorter and harder to get wrong. See structures, variables and the table reference.