ABAP Performance Tuning in Real Projects

Explanation

Performance tuning in ABAP means reducing database round-trips, memory footprint and CPU on the app server so programs stay fast as data grows. Common performance issues: - SELECT inside LOOP: fires one DB call per row; replace with a single SELECT + FOR ALL ENTRIES or a JOIN. - Missing WHERE conditions: full table scans on VBAK/BSEG kill runtime; always restrict on indexed key fields. - Wrong internal table type: STANDARD with linear reads on large sets — switch to SORTED or HASHED for key access. - READ TABLE without key: use READ TABLE ... WITH KEY ... BINARY SEARCH on sorted tables, or a HASHED table for O(1) lookups. - FOR ALL ENTRIES mistakes: forgetting the empty-driver check, or duplicates in the driver that require SORT + DELETE ADJACENT DUPLICATES. - Unnecessary nested loops: O(n*m). Pre-index the inner table (SORTED/HASHED) and use keyed READ. - Large data processing on the app server: use aggregation/pushdown (CDS views, AMDP) instead of pulling millions of rows. Diagnostics: - ST05 (SQL Trace): find expensive statements, identify missing indexes and repeated calls. - SAT (Runtime Analysis): profile ABAP code hotspots. - SQL Monitor (SQLM) / DBA Cockpit: production workload analysis. - Code Inspector / ATC with performance checks before transport.

Code example

* Bad: SELECT inside LOOPLOOP AT lt_vbak INTO ls_vbak.  SELECT SINGLE * FROM vbap INTO ls_vbap WHERE vbeln = ls_vbak-vbeln.ENDLOOP. * Optimized: bulk SELECT + FOR ALL ENTRIESIF lt_vbak IS NOT INITIAL.  SELECT vbeln posnr matnr netwr    FROM vbap    INTO TABLE @DATA(lt_vbap)    FOR ALL ENTRIES IN @lt_vbak   WHERE vbeln = @lt_vbak-vbeln.  SORT lt_vbap BY vbeln.ENDIF. LOOP AT lt_vbak INTO ls_vbak.  READ TABLE lt_vbap TRANSPORTING NO FIELDS       WITH KEY vbeln = ls_vbak-vbeln BINARY SEARCH.ENDLOOP.

Real project scenario

A monthly billing job on an S/4HANA project ran for 4+ hours because a nested LOOP hit VBRP with SELECT SINGLE per row. Replacing it with FOR ALL ENTRIES + a HASHED lookup table brought runtime under 12 minutes. ST05 confirmed the DB call count dropped from 2.1M to 47.

Common mistakes

- SELECT * without a field list. - FOR ALL ENTRIES without checking the driver table is not empty (returns all rows). - Sorting large internal tables inside a LOOP. - Using MOVE-CORRESPONDING in tight loops on wide structures. - Forgetting BINARY SEARCH on sorted internal tables.

Best practices

- Read only the fields you need; avoid SELECT *. - Always add restrictive, index-aligned WHERE clauses. - Prefer SORTED/HASHED tables for keyed access; STANDARD for sequential processing. - Use FOR ALL ENTRIES with an emptiness guard and de-duplicated driver. - Push heavy aggregation to CDS/AMDP on HANA. - Profile with ST05 + SAT before and after every change; keep the numbers in the transport note.

Interview angle

Typical questions: - Difference between FOR ALL ENTRIES and JOIN — when to use which. - How would you tune a report that runs 2 hours in production? - Walk me through an ST05 trace analysis. - Which internal table type would you pick for 5M rows and why? - How do you push aggregation down to HANA?