Internal Table Performance: Standard, Sorted and Hashed

Explanation

Internal table choice directly affects ABAP runtime. STANDARD tables are good for append and sequential processing, but repeated key lookups can become slow. SORTED tables keep data sorted and support efficient key/range access. HASHED tables are ideal for unique exact-key lookup. If a report loops over one table and repeatedly reads another standard table using key, performance can degrade badly. Using a hashed table for exact lookup or sorted table for range access can reduce runtime significantly.

Code example

* Purpose:* Use hashed table for repeated exact-key lookup.* This avoids scanning a standard table again and again. TYPES: BEGIN OF ty_mara_small, matnr TYPE matnr, mtart TYPE mtart, END OF ty_mara_small. DATA lt_mara_hash TYPE HASHED TABLE OF ty_mara_small WITH UNIQUE KEY matnr. * Fill hashed table from selected material datalt_mara_hash = CORRESPONDING #( lt_mara ). LOOP AT lt_items INTO DATA(ls_item).  * Fast exact-key lookup by MATNR READ TABLE lt_mara_hash INTO DATA(ls_mara) WITH TABLE KEY matnr = ls_item-matnr.  IF sy-subrc = 0. ls_output-mtart = ls_mara-mtart. ENDIF. ENDLOOP.

Real project scenario

A sales report repeatedly read material master details from a standard internal table for each item. Changing the lookup table to HASHED TABLE with key MATNR reduced ABAP time from 18 minutes to 40 seconds.

Common mistakes

- Using STANDARD table for repeated key lookup. - Sorting table repeatedly inside loop. - Using hashed table when duplicate keys are required. - Not defining proper table keys.

Best practices

- Use HASHED for repeated exact lookup. - Use SORTED for range and ordered access. - Use STANDARD for simple append/sequential flow. - Define meaningful keys.

Interview angle

Interviewers expect clear difference: STANDARD for sequential, SORTED for ordered/range access, HASHED for exact unique-key lookup.