ABAP FOR ALL ENTRIES vs SELECT in a LOOP: Runtime Calculator
A SELECT SINGLE inside a LOOP is one of the oldest ABAP performance mistakes, and one of the easiest to measure. This calculator compares the round-trip cost of per-row reads with a blocked FOR ALL ENTRIES read so you can justify the rewrite with numbers.
Your numbers
Rows in the internal table you loop over, for example open sales order items.
Database time plus network round trip for one indexed read. Take it from ST05 or SAT.
The driver table is split into blocks before it reaches the database. The size depends on your profile and database settings.
Parse, execute and round trip for one generated statement.
Transfer and move into the result table.
Your results
A planning model with linear costs. Real runtimes depend on buffering, indexes, database load and the generated SQL. Confirm with SAT and ST05 on your system.
Runtime in seconds as the driver table grows
Sweeps Driver table rows from 100 to 10000, holding your other inputs fixed.
Want a scan of your custom code for slow loops?
Optional: send us a description of your landscape and we will outline how to find and rank the worst SELECT patterns.
Optional. The tool and every export work without this. No spam.
How to use the calculator
Run your report with a trace in SAT or ST05 and note the average time of one single-row SELECT and the number of executions. Enter the driver row count, the per-statement cost and the cost of a block statement. The result shows both runtimes, the speed-up and a sweep chart so you can see where the curves separate. Small driver tables often show little difference, which is a valid finding: not every loop needs rewriting. Large driver tables show a steep nested line because every row pays a full round trip.
- Take statement timings from a real trace, not guesses
- Use the chart to find the row count where it starts to matter
- Re-test with production-sized data, not a 20 row test client
The model behind the numbers
Nested reads cost rows multiplied by the per-statement time. A FOR ALL ENTRIES read costs the number of blocks multiplied by the per-block time, plus a small per-row transfer cost. The block count is the driver rows divided by the block size, rounded up. This is why the gain grows roughly with the block size: you replace many round trips with few. On HANA, a JOIN or a CDS view pushed down to the database often beats both, because the join happens next to the data and only the result travels.
- Nested cost = rows x time per statement
- FAE cost = ceil(rows / block size) x block time + rows x row time
- A JOIN avoids the driver table entirely when both tables are on the same database
Rules that keep FOR ALL ENTRIES correct
FOR ALL ENTRIES silently removes duplicate rows from the result, so include the key fields or the SELECT list will lose data. If the driver table is empty, the WHERE clause is ignored and the whole table is read, which has caused real production incidents, so always check the driver table first. Sort the driver table and delete adjacent duplicates before the read, since duplicates add blocks without adding rows. Select only the columns you need, and never use FOR ALL ENTRIES against a driver table that can hold hundreds of thousands of rows without checking memory.
- Guard with IF driver_table IS NOT INITIAL
- Include key fields so duplicates are not collapsed
- Delete duplicates in the driver table first
- Prefer a JOIN or CDS view when the data sits in one database
Frequently Asked Questions
Is FOR ALL ENTRIES always faster than SELECT in a LOOP?
Not always. With a handful of driver rows the difference is negligible, and a buffered table read inside a loop can be fine. The gain appears when the driver table is large and each read goes to the database. Measure with a trace before rewriting.
What happens if the driver table is empty?
The WHERE condition that references the driver table is dropped and the SELECT can return every row of the table. Always test that the driver table has entries before the statement runs.
Should I use a JOIN instead?
Often yes. If the data lives in the same database, a JOIN or a CDS view lets the database do the matching and avoids moving the driver table. FOR ALL ENTRIES is best when the driver data comes from somewhere else, such as an earlier application step.
Where do I get the per-statement time?
Use transaction ST05 (SQL trace) or SAT (runtime analysis). Both show the number of executions and the duration per statement, which are the figures this calculator needs.
If you maintain hundreds of custom reports, finding the slow loops is the real work. Netray can help scan custom code for these patterns and prioritise the rewrites.
Related Tools
ABAP Internal Table Memory Size Calculator
Estimate the memory an internal table needs, check it against a session limit and find the safe row count before you hit a short dump.
SAPABAP Background Job Runtime and Batch Window Calculator
Estimate batch job duration from record volume, per-record time, commit frequency and parallel processing, and test it against your batch window.
SAPABAP RICEFW Estimation Worksheet
List each report, interface, conversion, enhancement, form and workflow, enter hours and risk, and get totals and cost.
SAPSAP Dialog Work Process Sizing Calculator
Turn active users, dialog steps per hour and work process time into the number of dialog work processes needed at peak.
More SAP tools
See all- SAP Sales Document Types Reference
- SAP Pricing Procedure Design Worksheet
- SAP Item Category Determination Reference
- SAP Delivery Block Reasons Template
- SAP Credit Management Checklist
- SAP Output Determination Checklist
- SAP Billing Types Reference
- SAP Incompletion Log Checklist
- SAP SD Tables Reference (VBAK, VBAP, LIKP, VBRK and More)