ABAP Performance Tuning in ECC: Hard-Earned Lessons from 25 Years in the Code

Arjun Mehta cuts through the clutter with techniques that actually move the needle

Last month I walked into a client’s war room at 3 a.m. A month-end billing report that ran flawlessly for years was now timing out after 40 minutes. The database wasn’t the culprit—a quick SM66 glance showed a single ABAP session chewing 90% of a CPU core. The same code, same data volume, but one poorly placed SELECT in a loop had turned a background job into a business crisis.

That incident mirrors hundreds I’ve debugged since 1999, first as a fresh ABAPer at Infosys and now through my own consulting practice. The common thread? Developers often write code that “works,” but never look under the hood. In this article, I want to share the three areas that consistently deliver performance wins in ECC systems, with specific, copy-paste-ready corrections.

The Real Story: Where ECC Reports Bleed Time

Most ECC performance issues I encounter aren’t caused by missing indexes or hardware. They stem from three coding habits:

• SELECT * fetching 50 columns when only 5 are needed, bloating DB-application server communication.
• LOOPs that execute a fresh database hit for every line of a 100,000-row internal table.
• Standard internal tables used for lookup operations that could run 20x faster as hashed tables.

The remedy is methodical, not magical. Let’s break down each area with before-and-after code from my battlefield playbook.

SQL Tuning: Stop Paying for Data You Never Use

I still find SELECT * FROM VBAK in production code. Developers argue it’s “future-proof.” In reality, it’s a bandwidth tax. Every unnecessary field travels from the database server through the network to the application server, and then gets discarded when the work area isn’t fully referenced.

Before:

SELECT * FROM vbap INTO TABLE @DATA(lt_vbap)
  WHERE vbeln IN @s_vbeln.

This pulls all VBAP fields, including raw flag bytes and last-change timestamps you’ll never touch.

After:

SELECT vbeln, posnr, matnr, netwr, waerk
  FROM vbap
  INTO TABLE @DATA(lt_vbap)
  WHERE vbeln IN @s_vbeln.

On a table with 200 columns, the difference can exceed 90% less data transfer. I combine this with appropriate JOINs instead of nested selects. For header-item logic, one INNER JOIN on VBAK and VBAP performs infinitely better than retrieving headers and then looping over items.

A common oversight: never join on a field without a proper index unless you’ve verified the optimizer plan via ST05. In a recent migration from ECC 6.0 EhP4 to EhP8, a join on a user-defined Z-field without secondary index turned a 2-second query into a 200-second monster.

Internal Table Intelligence: Sorted, Hashed, and Field Symbols

In the early 2000s, most of us defaulted to STANDARD TABLE. For straight sequential processing that’s fine. But when you need READ TABLE ... WITH KEY inside a tight loop, a standard table imposes linear search overhead.

Real example: a purchasing reconciliation program that matched 50,000 EKPO lines against a custom Z-table of approved price thresholds. The original code:

READ TABLE lt_threshold INTO ls_thresh WITH KEY matnr = ls_ekpo-matnr.

lt_threshold was a standard table of 30,000 entries. Every read scanned on average half the table, totaling 750 million key comparisons.

After changing the declaration to:

DATA lt_threshold TYPE HASHED TABLE OF zthresh WITH UNIQUE KEY matnr.

The same READ TABLE used a hash lookup, reducing the entire matching step from 4 minutes to 0.3 seconds.

Even when a UNIQUE key isn’t possible, a SORTED TABLE with BINARY SEARCH can cut search time drastically. I prioritize hashed tables for any lookup table that fits in memory, followed by sorted tables for range-based reads.

Additionally, when iterating a table purely for read access, replacing work areas with field symbols eliminates an implicit data copy. I use:

LOOP AT lt_vbap ASSIGNING FIELD-SYMBOL(<fs_vbap>).
  " process <fs_vbap>-netwr
ENDLOOP.

This avoids the MOVEs that silently consume CPU time. I’ve measured up to 15% reduction in loop runtime on large tables just by this switch.

Breaking the Loop-SELECT Habit

The most painful pattern in ECC is a SELECT statement inside a LOOP. I’ve seen code that for each of 10,000 deliveries fetches the corresponding shipment from VTTP, then the carrier details from LIKP, one row at a time. That’s 30,000 database round-trips, each with parsing overhead.

The fix is not always FOR ALL ENTRIES. While FAE works well for small to medium result sets, on very large internal tables it can generate a long IN-list that confuses the optimizer and hits SQL parsing limits. I first ensure the driving table is deduplicated and not empty (FAE on an empty table returns all rows). A safer approach for lookup-heavy logic:

• Fetch all needed target data into one internal table with a single SELECT that covers the range.
• Then use a hashed table for the lookup fields.

Example: Instead of looping over VBRK billing documents and selecting VBRP items inside the loop, I select all VBRP for the date range into a hashed table indexed by VBELN, then loop over VBRK and use READ TABLE. The DB round-trip count drops to two, regardless of data size.

Tools I Reach For Every Time

No ABAPer should rely on intuition alone. I tap three transaction codes relentlessly:

• ST05 (SQL trace): The ultimate truth-teller. I filter by the program, execute, and immediately eyeball the duration column. If a single statement accounts for more than 5% of runtime, it’s a target.
• SAT (Runtime Analysis): Useful for non-database bottlenecks, like nested internal table loops that don’t touch the DB. I’ve uncovered costly string operations this way.
• Code Inspector (SCI) with performance checks: It won’t catch everything, but I run it before any code review. It flags SELECT *, missing BINARY SEARCH, and the absence of ORDER BY keys that could deceive a developer.

One final tip: When using ST05, do not trace with aggregation turned on initially; the detailed record often reveals the exact row count and execution plan that explain why an index isn’t used.

Bottom Line

ECC ABAP performance tuning is not about rewriting everything in HANA-optimized style. It’s about respecting the cost of each statement. Reduce data transfer with precise field lists, pick the right internal table type for the job, and never let a LOOP spawn database chatter. After 25 years, I can say with confidence that 80% of the performance gains I’ve delivered came from fixing these three fundamental patterns. The tools to find them are free and waiting in your system. The only missing piece is the discipline to look.

Source: Original discussion/article

References

• ABAP Development Guide
• SAP Community Hub

References

• ABAP Development Guide
• SAP Community Hub
• Performance Optimization in SAP ABAP ECC | Best Practices