Your report works. But it takes 15 minutes to run. The user is furious. Your manager wants answers. That is the moment when performance tuning becomes not a nice-to-have skill, but a survival skill.

Every ABAP developer eventually hits this wall. The code is correct — it produces the right output — but it is too slow. In this chapter, you will learn how to measure performance (ST05 and SAT), how to diagnose the bottleneck, and how to fix the top performance killers in ABAP code.

🎯 What You Will Learn in This Chapter

• What performance tuning is and why it matters
• How to use ST05 (SQL Performance Trace)
• How to use SAT (Runtime Analysis)
• The difference between ST05 and SAT and when to use each
• What Code Pushdown is and why HANA changed the rules
• The most common performance killers (and how to fix them)
• How to use table buffering and internal table types correctly
• How to use parallel processing for large jobs
• A systematic process to optimize any slow report

📘 Why Performance Tuning Matters

Performance tuning is not about making code “cleaner” — it is about making it faster and using fewer resources. There are three reasons this matters enormously in SAP:

The good news: 90% of performance problems come from just five or six common mistakes. Fix those and your code runs dramatically faster.

🔍 Tool 1: ST05 — SQL Performance Trace

ST05 is the SQL Performance Trace. It records every database access made by your program — SELECT, INSERT, UPDATE, DELETE, RFC calls, buffer accesses, and enqueue operations.

When to use ST05

• Your program is slow and you suspect the database is the bottleneck
• A report takes many minutes but you do not know which query is slow
• You want to see how many database round-trips your program makes
• You want to identify missing indexes on WHERE clauses

How to run an ST05 trace

What to look for in the trace

📊 Tool 2: SAT — Runtime Analysis

SAT measures the execution time of your ABAP code at the statement level. It tells you exactly which methods, function modules, and statements consume the most time inside ABAP itself.

When to use SAT

• ST05 shows the database is fine, but the report is still slow
• You want to know which internal processing (LOOPs, string operations, conversions) is slow
• You are comparing two implementations and want hard numbers
• You need to prove a performance improvement to a stakeholder

How to run a SAT trace

What to look for in SAT results

⬇️ Code Pushdown — The HANA Revolution

Code Pushdown is the practice of moving data processing from the ABAP application server to the database server.

In old SAP systems (ECC on Oracle, DB2, SQL Server), the database was slow. So ABAP developers read data into internal tables and processed it there — filtering, sorting, summing in ABAP code. This was faster because ABAP was the “fast” layer.

S/4HANA changed everything. HANA is an in-memory database. It can process billions of rows in milliseconds. Now, it is faster to let the database do the heavy work and only return the final result to ABAP.

Before (Classic ABAP)

" Read ALL invoices from the table
SELECT * FROM vbrk INTO TABLE @DATA(lt_all_invoices).

" Then filter and sum in ABAP
LOOP AT lt_all_invoices INTO DATA(ls_inv).
  IF ls_inv-fkdat >= '20260101' AND ls_inv-fkart = 'F2'.
    lv_total = lv_total + ls_inv-netwr.
  ENDIF.
ENDLOOP.

After (Code Pushdown)

" Let the database do all the work
SELECT SUM( netwr ) FROM vbrk
  INTO @DATA(lv_total)
  WHERE fkdat >= @DATA(lv_from)
    AND fkart  = 'F2'.

Techniques that support Code Pushdown

• Aggregate functions in SQL — SUM, AVG, MAX, MIN, COUNT
• INNER JOIN / LEFT OUTER JOIN — combine tables in one query instead of nested SELECTs
• String functions in SQL — CONCAT, SUBSTRING, UPPER, LOWER
• CASE expressions — conditional logic in the SQL itself
• CDS Views — the ultimate pushdown (covered in Chapter 16)

🚫 The Top Performance Killers (And How to Fix Them)

Killer #1 — SELECT inside a LOOP (nested SELECT)

" ❌ WRONG — 500 queries for 500 rows
LOOP AT lt_orders INTO DATA(ls_order).
  SELECT SINGLE name1 FROM kna1
    INTO DATA(lv_name)
    WHERE kunnr = ls_order-kunnr.
  WRITE: / lv_name.
ENDLOOP.

" ✅ RIGHT — one query for all rows
SELECT kunnr, name1 FROM kna1
  INTO TABLE @DATA(lt_customers)
  FOR ALL ENTRIES IN @lt_orders
  WHERE kunnr = @lt_orders-kunnr.

SORT lt_customers BY kunnr.
LOOP AT lt_orders INTO DATA(ls_order).
  READ TABLE lt_customers INTO DATA(ls_cust)
    WITH KEY kunnr = ls_order-kunnr
    BINARY SEARCH.
  WRITE: / ls_cust-name1.
ENDLOOP.

Killer #2 — SELECT * (reading all columns)

" ❌ WRONG — reads all 200 columns
SELECT * FROM vbak INTO TABLE @DATA(lt_orders).

" ✅ RIGHT — reads only 4 columns you need
SELECT vbeln, erdat, kunnr, netwr FROM vbak
  INTO TABLE @DATA(lt_orders).

Killer #3 — FOR ALL ENTRIES with empty table

" ❌ WRONG — if lt_orders is empty, reads the WHOLE table
SELECT kunnr, name1 FROM kna1
  INTO TABLE @DATA(lt_customers)
  FOR ALL ENTRIES IN @lt_orders
  WHERE kunnr = @lt_orders-kunnr.

" ✅ RIGHT — check the driver table is not empty
IF lt_orders IS NOT INITIAL.
  SELECT kunnr, name1 FROM kna1
    INTO TABLE @DATA(lt_customers)
    FOR ALL ENTRIES IN @lt_orders
    WHERE kunnr = @lt_orders-kunnr.
ENDIF.

Killer #4 — LOOP AT … WHERE (no sort, no index)

" ❌ WRONG — scans the whole table every iteration
LOOP AT lt_items INTO DATA(ls_item) WHERE matnr = lv_matnr.
  " ...
ENDLOOP.

" ✅ RIGHT — use a SORTED or HASHED table with the key
DATA lt_items TYPE SORTED TABLE OF ty_item
  WITH UNIQUE KEY matnr.
READ TABLE lt_items INTO DATA(ls_item)
  WITH TABLE KEY matnr = lv_matnr.

Killer #5 — Using the wrong internal table type

Killer #6 — Missing table buffering

Tables like T001 (company codes), T005 (countries), T005T (country texts), and TCURR (exchange rates) are small, read-heavy, and rarely updated. They should be buffered — meaning SAP caches them in the application server memory.

To buffer a table: In SE11, open the table’s Technical Settings. Set Buffering to “Buffered” and choose Full or Generic buffering. Full buffering is best for small tables; generic buffering for larger ones with a common access pattern.

⚡ Parallel Processing — Doing Many Things at Once

Sometimes you cannot make a single task faster — but you can run many tasks in parallel. Parallel processing splits a large job into multiple background tasks that run simultaneously.

Classic pattern — CALL FUNCTION IN BACKGROUND TASK

DATA: lt_tasks TYPE TABLE OF ty_task.

" 1. Split work into chunks and start parallel tasks
LOOP AT lt_chunks INTO DATA(ls_chunk).
  CALL FUNCTION 'Z_PROCESS_CHUNK'
    STARTING NEW TASK lv_task_id
    PERFORMING on_task_done ON END OF TASK
    EXPORTING
      iv_chunk = ls_chunk.
  lv_task_id = lv_task_id + 1.
ENDLOOP.

" 2. Wait for all tasks to complete
WAIT UNTIL lv_tasks_completed = lv_tasks_started.

" 3. Handler FORM
FORM on_task_done USING p_taskname.
  RECEIVE RESULTS FROM FUNCTION 'Z_PROCESS_CHUNK'
    IMPORTING ev_result = DATA(lv_result).
  lv_tasks_completed = lv_tasks_completed + 1.
ENDFORM.

🎯 A Systematic Approach to Optimize Any Report

Here is the process senior ABAP developers follow when a report is slow.

📝 Chapter Summary

• Performance tuning is the difference between working code and production-ready code.
• ST05 — SQL Performance Trace. Records every database call. Use it to find slow queries.
• SAT — Runtime Analysis. Records ABAP execution time at statement level. Use it when the database is fine but ABAP is slow.
• Code Pushdown — move processing to the HANA database. Use SUM, JOIN, and string functions in SQL.
• The top 6 performance killers: SELECT in LOOP, SELECT *, FOR ALL ENTRIES without empty check, LOOP AT … WHERE, wrong table type, missing buffering.
• Parallel processing — split large jobs into multiple background tasks to reduce total runtime.
• Follow a systematic process: measure → trace → identify → fix → re-measure.
• Never optimize by guessing. Measure first, fix the biggest offender, verify.