Optimize ABAP Loops: Switch to HASHED Tables and ASSIGN

Sara Kim breaks down what you need to know

In many SAP systems, a single LOOP over a 500,000-row internal table still dominates runtime. Two targeted changes—switching to HASHED tables for key access and replacing INTO with ASSIGN—often deliver the largest gains without touching business logic.

The Real Story

Standard internal tables store rows sequentially. READ TABLE or LOOP with a key performs a linear or binary search unless you explicitly declare the table HASHED. Each iteration of LOOP … INTO wa also copies the entire row into the work area, adding measurable overhead once the row exceeds a few hundred bytes.

The SAP documentation on internal table access confirms that HASHED tables deliver constant-time key access and that field-symbol assignment avoids the copy step. In practice, these two facts matter more than most other micro-optimizations.

What This Means for You

Developers maintaining nightly batch jobs or real-time interfaces notice the difference immediately. A 40-second report drops to 12 seconds after converting the main lookup table to HASHED and rewriting the loop. Code reviewers see fewer temporary variables and clearer intent when field symbols replace work areas.

The change does require stable key definitions. If your process occasionally needs sorted output or range scans, a HASHED table forces an extra SORT or a second table, so measure before refactoring.

Action Items

• Identify tables accessed only by full key in hot paths; declare them as HASHED TABLE with a unique key that matches the access pattern.
• Replace LOOP AT itab INTO wa with LOOP AT itab ASSIGNING FIELD-SYMBOL() when the row is only read or updated in place.
• Keep a sorted secondary table only when you truly need sequential or range access; profile both versions.
• Add a short runtime measurement (GET RUN TIME FIELD) around the changed block so future regressions surface quickly.

TYPES: BEGIN OF ty_order,
         order_id TYPE vbeln,
         amount   TYPE netwr,
       END OF ty_order.

DATA: ht_orders TYPE HASHED TABLE OF ty_order
                WITH UNIQUE KEY order_id.

FIELD-SYMBOLS: <order> TYPE ty_order.

LOOP AT ht_orders ASSIGNING <order>.
  <order>-amount = <order>-amount * lv_factor.
ENDLOOP.

Community Perspective

Teams that adopted these patterns report the biggest wins in data-migration and reconciliation programs. Several developers note that static code checks now flag large LOOP … INTO constructs, making the change part of the standard review checklist. A few projects initially over-used HASHED tables for small, frequently sorted datasets and saw minor regressions until they reintroduced SORTED tables for those cases.

Bottom Line

HASHED tables plus ASSIGN deliver reliable, measurable improvements when the access pattern is key-driven and the row count is large. They are not universal replacements. Profile first, keep the key definition stable, and you will remove the most common internal-table bottlenecks without introducing new complexity.

Source: Original discussion/article

References

• ABAP Development Guide
• SAP Community Hub

References

• ABAP Performance and Tuning
• ABAP Development Guide
• SAP Community Hub