Performance Optimization

Typical workflow: reproduce → ST05 to find expensive/duplicate SQL → SAT for ABAP hotspots → fix → measure again.

32.1 Golden rules for database access

Keep the result set small: select only needed columns (no SELECT * on wide tables), use precise WHERE conditions.

Minimize data transfer and round trips: INTO TABLE instead of SELECT … ENDSELECT; no SELECT inside LOOP ("N+1 problem") — use joins, CDS, or FOR ALL ENTRIES.

Use indexes (or on HANA, rely on column store; avoid functions on columns in WHERE).

Push down logic to the database: aggregates, CASE, joins, CDS views, AMDP — code-to-data paradigm.

Use buffering for small, read-mostly customizing tables (and don't bypass it unnecessarily).

" BAD: nested selects
LOOP AT lt_orders INTO DATA(ls_o).
  SELECT SINGLE name1 FROM kna1 WHERE kunnr = @ls_o-customer INTO @DATA(lv_name).
ENDLOOP.

" GOOD: one join
SELECT o~order_id, o~amount, k~name1
  FROM zorders AS o INNER JOIN kna1 AS k ON k~kunnr = o~customer
  WHERE o~status = 'O'
  INTO TABLE @DATA(lt_result).

32.2 Internal table performance

Use the right table category (§10) and keys; avoid nested loops over big standard tables — use hashed lookups or parallel cursor technique.

Use ASSIGNING/REFERENCE INTO; avoid copying deep structures.

DELETE … WHERE beats deleting row by row; SORT only once.

Avoid string concatenation in tight loops with && on huge strings (use concat_lines_of or string_table).

32.3 Tools

SQL trace (Performance Trace) Record DB statements, durations, identical selects, explain plan ABAP runtime analysis SAT (successor of SE30)

Hit lists, call hierarchy, gross/net time per statement SAT-based profiling inside Eclipse with flame graphs

Production-wide SQL statistics, combined with static checks SQL Performance Tuning Worklist Prioritize findings (SQLM + ATC) Code Inspector / ATC

Static performance checks (SELECT in loop, missing WHERE) Work process / workload SM50, ST03N, STAD

System load, response times per transaction Memory snapshots and leaks

Typical workflow: reproduce → ST05 to find expensive/duplicate SQL → SAT for ABAP hotspots → fix → measure again.

32.4 HANA-specific advice (code pushdown)

HANA is columnar and in-memory: wide SELECT * is expensive (each column decompressed); aggregation is cheap.

Prefer CDS views and SQL expressions over ABAP loops for calculations on large data.

Use ALV IDA for large lists, AMDP for complex procedural logic in SQLScript.

Avoid FOR ALL ENTRIES with huge driver tables; use joins or select from internal tables (FROM @itab).

Secondary indexes are rarely needed on HANA.

32.5 Other techniques

Parallelization: aRFC (§27.2), CL_ABAP_PARALLEL, SPTA_PARA_PROCESS_START_2, parallel background jobs.

Caching: shared memory (shared objects), static attributes, table buffering.

GET RUN TIME FIELD DATA(t1).
" ... code to measure ...
GET RUN TIME FIELD DATA(t2).
WRITE: / |Runtime: { t2 - t1 } microseconds|.