# ABAP Performance Tuning Checklist > Source: https://netray.co/tools/abap-performance-tuning-checklist > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Free Tools ## Short answer A checklist of database, internal table and memory checks to run on slow ABAP reports before they reach production. ## Category sap ## Erp SAP ECC / S/4HANA ## Audience - ABAP developer - SAP performance engineer ## Tool **Kind:** checklist **Groups:** #### Database access **Items:** **Text:** No SELECT inside a LOOP or DO; data is read once, ahead of the loop **Critical:** true **Text:** Only the needed columns are selected; no SELECT * on wide tables **Critical:** true WHERE conditions use the primary key or an existing index, in key order **Text:** FOR ALL ENTRIES driver table is checked for being empty before use **Critical:** true JOINs are used where they replace nested selects, with indexed join conditions SELECT SINGLE is used only with the full primary key Aggregates (SUM, COUNT, MAX) are done in the database, not by looping in ABAP Large reads use package size or cursors instead of loading all rows Buffered tables are read from the buffer, with no BYPASSING BUFFER unless required #### Internal tables **Items:** **Text:** Tables read by key inside loops are SORTED or HASHED, not STANDARD with linear scans **Critical:** true READ TABLE on a standard table uses BINARY SEARCH only after a SORT on the same key Table work areas use field symbols or REFERENCE INTO for wide rows **Text:** No nested LOOP over two large standard tables **Critical:** true DELETE ADJACENT DUPLICATES is preceded by a SORT on the compared fields APPEND is used instead of INSERT INTO TABLE for standard tables when order is irrelevant Table is freed with FREE or CLEAR when no longer needed #### Memory and strings **Items:** **Text:** Memory use is estimated for the largest realistic data volume **Critical:** true Large files and result sets are processed in packages String building uses string templates or a single concatenation, not repeated growth in a loop Deep structures are not copied needlessly; parameters are passed by reference No unnecessary EXPORT TO MEMORY of large tables #### Analysis and measurement **Items:** **Text:** A runtime trace in SAT shows where the time goes before any change is made **Critical:** true An SQL trace in ST05 confirms the number of database calls and index use The EXPLAIN or execution plan of expensive statements was reviewed Code Inspector performance checks have been run on the object Tests used realistic data volumes, not a small development client Before and after run times are recorded in the change ticket #### S/4HANA and design **Items:** Heavy calculations are pushed down to CDS views or AMDP where it makes sense Code pushdown is checked against HANA SQL limitations and release Background jobs are used for long runs with a defined server group Parallelisation (parallel RFC or bgRFC) is considered only after single thread tuning **Text:** Selection screen forces restrictive criteria to avoid full table scans **Critical:** true **Scoring Note:** Critical items are the ones that most often cause production time-outs and memory dumps. Fix all critical items before tuning anything else, and measure before and after each change. ## Content **Intro:** Slow ABAP programs usually fail in the same few ways: SELECT in a loop, linear reads on large standard tables, reading far more columns than needed, and no measurement. This checklist gives you the checks to run before release, grouped by database access, internal tables, memory and analysis. **Sections:** #### How to use the checklist **Body:** Run through the groups on the program you are about to transport, ticking each item you have checked. Start with measurement: take a trace in SAT and an SQL trace in ST05 so you know the real cost centres instead of guessing. Then fix the critical items first, repeat the measurement and note the before and after in the change ticket. Export your ticked list to PDF or Excel as evidence for review. #### Database access rules **Body:** The database is usually where the time goes. Reduce the number of round trips by reading once and processing in memory, reduce the data volume by selecting only the needed columns and rows, and make the database use an index by filtering on key or indexed fields. FOR ALL ENTRIES with an empty driver table selects the whole table, which is a classic production incident, so always test the driver table first. On HANA, push aggregation into the SELECT. **Bullets:** - One SELECT before the loop, not one per iteration - Explicit field lists - Full key for SELECT SINGLE - Check the driver table of FOR ALL ENTRIES #### Internal table access **Body:** A READ TABLE on a standard table scans linearly, which is fine for ten rows and painful for a hundred thousand inside a loop. Use a sorted or hashed table with the key you read by, or a standard table sorted once and read with binary search. Hashed tables give near constant time reads by unique key, and sorted tables help with range access and partial keys. Choose the table type at declaration based on how you will access it. #### Measure, then change **Body:** Do not tune by intuition. A trace shows if the time is in the database, in ABAP or in a remote call. Compare runs with the same data and a warm buffer, and run the final check with a realistic volume. Document the result, because performance regressions usually return after later changes. Add a performance test to your release routine for programs that run in business-critical windows such as month-end or MRP. **Cta:** If a long-running custom report is slowing your plant or finance close, Netray can discuss reviewing it with a private AI assistant that works on your own code, with developers approving every change. **Faq:** #### Why is SELECT inside a loop so slow? **Answer:** Each SELECT is a database round trip with its own parsing and network cost. A loop with ten thousand iterations makes ten thousand round trips, where one set-based SELECT could fetch all rows at once. Read the data once into an internal table and look it up in memory. #### What is wrong with FOR ALL ENTRIES and an empty table? **Answer:** If the driver table is empty, the WHERE condition based on it is dropped and the statement reads the whole table. Always check that the driver table has rows before the SELECT. Also remember that FOR ALL ENTRIES removes duplicate result rows, which can change counts. #### When should I use a hashed table? **Answer:** Use a hashed table when you read single rows by a complete unique key very often, such as looking up material descriptions by material number. For range access or partial key reads, a sorted table is usually the better choice. #### Which tools show where the time is spent? **Answer:** SAT, the ABAP runtime analysis, shows time per statement and call. ST05 traces SQL, RFC and enqueue calls and shows the number of executions and duration. The Code Inspector flags known performance anti-patterns statically before you run anything. ## Search terms abap performance tuning, abap select optimization, abap internal table performance, sorted table hashed table, abap for all entries, st05 sql trace tips, abap code inspector performance, abap slow report checklist --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json