SAP ABAP Internal Tables Interview Questions

LOOP AT itab INTO wa physically copies each row's data from the internal table into the work area's separate memory area on every iteration; any change to wa does not automatically reflect back into the table unless you explicitly issue a MODIFY itab FROM wa statement. LOOP AT itab ASSIGNING <fs> does not copy data - the field symbol becomes a direct alias pointing to the actual memory of that row inside the internal table, so any change made through <fs> immediately updates the table in place, with no separate MODIFY needed. For large internal tables processed in tight loops, avoiding the row copy by using ASSIGNING can meaningfully reduce CPU and memory overhead, especially when the work area/structure is wide (many fields) or when the loop runs for hundreds of thousands of iterations. This is a standard performance optimization technique in production-grade ABAP code, particularly for reports and interfaces processing large data volumes.

By default, READ TABLE ... WITH KEY on a standard table performs a linear scan through the rows, checking each one until a match is found, which is O(n) in the worst case. Adding BINARY SEARCH tells the runtime to instead perform a binary search on the table, achieving O(log n) complexity, which is significantly faster for large tables. However, BINARY SEARCH only produces correct results if the internal table is actually sorted by the key fields used in the WITH KEY condition, in the correct sort sequence - if the table isn't sorted on those fields (or is sorted on different fields), BINARY SEARCH can silently return a wrong row or no row at all, because the algorithm assumes ordering and simply won't find data correctly otherwise. Because of this fragile precondition, many senior developers prefer to declare the internal table as a SORTED table type from the start (which guarantees the order automatically) rather than relying on a standard table with a manual SORT plus BINARY SEARCH, since the manual approach is easy to break if someone modifies the table later without re-sorting.

A Standard table stores rows in the sequence they are inserted (via APPEND) and can have a non-unique key or no key at all; it supports both index-based access (fast, direct offset) and key-based access (linear scan unless BINARY SEARCH is used on a sorted content). A Sorted table always maintains its rows in ascending or descending order based on a defined key (unique or non-unique), and the system automatically keeps this order on every INSERT; key-based access uses binary search internally, making it efficient even without manually sorting. A Hashed table must have a unique key and has no linear index at all - it can only be accessed via READ TABLE WITH TABLE KEY using a hash algorithm, giving near-constant time access regardless of size, but INDEX-based operations like LOOP ... FROM/TO or READ TABLE INDEX are not meaningful for it. In practice, standard tables are the default and most flexible choice, sorted tables suit scenarios needing ordered processing with frequent key lookups, and hashed tables are ideal for large lookup/reference tables accessed repeatedly by unique key.

A primary table (standard, sorted, or hashed) is optimized for access via its primary key or index, but real programs often need to look up the same table by a different, non-primary field combination. A secondary key lets you define an additional sorted or hashed index on a standard or sorted table (declared using the SECONDARY KEY addition in the TYPES/DATA statement, e.g. ... WITH NON-UNIQUE SORTED KEY sec_key COMPONENTS field1 field2 or WITH UNIQUE HASHED KEY), so that a READ TABLE ... USING KEY sec_key or LOOP AT ... USING KEY sec_key can access the table efficiently by that alternate field combination instead of falling back to a full linear scan. This is very useful when the same internal table needs to be read frequently by two different criteria in different parts of a program - for example, a sales item table primarily indexed by VBELN/POSNR but also frequently looked up by MATNR, where adding a secondary hashed key on MATNR avoids a linear scan each time. Secondary keys do add maintenance overhead on insert/update since the additional index structure must be kept in sync, so they should be added only where the alternate access pattern is genuinely frequent.

APPEND adds a row at the end of a standard internal table. It is not suitable for hashed tables, and for sorted tables it is only safe when the appended row keeps the defined sort order; otherwise a runtime error can occur. INSERT is more general: for a standard table it can insert at a specific index, while for sorted and hashed tables it inserts the row according to the table key structure. COLLECT is different in purpose: it aggregates. If a row with the same key/non-numeric fields already exists, COLLECT adds the numeric fields of the new row to the existing row's numeric fields instead of creating a duplicate; if no matching row exists, it inserts a new row. COLLECT is commonly used for summary/aggregation internal tables, such as totals by material or vendor, but it should be used carefully because the key behavior must be clearly understood.

For a header-with-variable-items structure, I would model it using a nested table approach: define an item line type (a structure matching the fields needed per item), then define a standard table type of that item structure, and finally define a header structure that includes one component of this item table type as a deep component (a table-typed field inside the header structure) - this creates a 'deep' internal table where each header row itself contains a nested internal table of its items. This is appropriate when the items always need to travel together with their header as a single unit (e.g., building a single BAPI/RFC parameter for a document, or preparing structured data for a nested JSON/XML mapping). Alternatively, and often preferred for typical reporting/processing scenarios, I would keep two separate flat internal tables - one for headers (keyed on VBELN) and one for items (keyed on VBELN/POSNR) - and use a sorted or hashed key structure so items for a given header can be looked up efficiently (e.g., using a secondary sorted key on VBELN in the item table, or LOOP AT items WHERE vbeln = header-vbeln using a key). The two-flat-table approach is usually easier to process with standard ABAP statements (SELECT, LOOP, control breaks) and generally has simpler memory management, while the deep/nested table approach is better suited when the data structure needs to be passed as a single self-contained unit to an interface or recursive processing routine.

For a sorted table, APPEND is only allowed if the row being appended would actually maintain the table's defined sort order at the end - meaning its key value must be greater than (or equal to, if non-unique) the last row currently in the table. If the incoming data isn't already pre-sorted in the exact order matching the table's key, at some point a row will need to be inserted somewhere in the middle to maintain sort order, and APPEND cannot do that - it raises a runtime error (a table-key related exception) because APPEND assumes end-of-table insertion is valid for the current data being added, which fails if the data isn't already appropriately ordered. This is why it works 'sometimes' - it happens to succeed when incoming data coincidentally arrives in a way compatible with append-at-end, and fails when it doesn't. The correct fix is to use INSERT INTO the sorted table instead of APPEND (INSERT lets the runtime automatically place the row in the correct sorted position based on the key), or, if performance-critical and the source data can be guaranteed sorted beforehand, explicitly SORT the source data by the same key before looping through and appending. In general, INSERT is the safe, always-correct choice for sorted tables unless there's a proven guarantee about incoming data order.

I would ensure both the old and new snapshot internal tables are declared with the same key structure (ideally as sorted tables keyed on the business key, e.g., document number, or at least sorted explicitly before comparison) so that a single-pass merge-style comparison can be done instead of a nested loop. I would loop through the new snapshot table and, for each record, use READ TABLE old_snapshot WITH TABLE KEY (if sorted/hashed) or BINARY SEARCH (if standard but sorted) to check if the same key exists in the old snapshot: if not found, it's an insert; if found, I'd compare the relevant fields between the two records (either field by field or, if both structures are identical in layout, a direct structure comparison using = between the two work areas/rows, which ABAP supports natively for compatible structures) to detect a change, tagging it as an update if different, or no-op if identical. Then I would loop through the old snapshot and check for keys not present in the new snapshot (using the same key-based lookup) to identify deletions. To do this efficiently, I would use hashed or sorted tables for whichever side is being looked up (typically the old snapshot, since it's read repeatedly), so each check is O(1) or O(log n) rather than a linear scan, keeping the overall comparison close to O(n) rather than O(n*m).

I would use two internal tables serving different purposes: a detail table (standard table) holding the raw purchase order item rows as fetched, sorted by vendor (LIFNR) and then by document/item, and a separate summary table (could be built using COLLECT) keyed by vendor to accumulate the running total per vendor - looping once through the sorted detail table and using COLLECT (or manually READ TABLE WITH KEY + ADD if COLLECT's field-matching doesn't fit) into the summary table keyed on LIFNR with the accumulated amount. For producing the final combined output (detail rows plus a subtotal line after each vendor), I would process the sorted detail table using AT END OF LIFNR (a control-break statement) to trigger writing the subtotal for that vendor's group right after processing its last detail row, using the corresponding value already accumulated in the summary table (looked up via READ TABLE WITH KEY lifnr) or an accumulator variable reset AT NEW LIFNR. This design avoids re-scanning the detail table multiple times - one pass builds the summary, and either a second pass or interleaved AT NEW/AT END logic produces the final formatted output with subtotals in the correct position.

FOR ALL ENTRIES should be treated as a set-based lookup, not as a row-by-row join back to the driver table. When the driver internal table contains duplicate key combinations, the database result normally represents the matching database rows for the distinct key combinations, not a guaranteed 1:1 result row for every driver row. So the common bug is not that duplicates in the driver table directly 'lose' database rows; the real bug is downstream code assuming positional or row-count correspondence between driver rows and result rows. For example, code that loops by index over the driver table and the result table can break because repeated driver keys do not produce repeated result rows in the same sequence. The fix is to remove positional assumptions entirely: deduplicate the driver table intentionally before the SELECT (SORT + DELETE ADJACENT DUPLICATES), perform the FOR ALL ENTRIES only after checking the driver table is not empty, then store the result in a hashed or sorted internal table and join it back to the original driver data using explicit key-based READ TABLE logic.

A very common cause is that MODIFY itab FROM wa without a TRANSPORTING clause and without an explicit INDEX inside a LOOP AT itab INTO wa relies on the system variable sy-tabix set by the LOOP statement to know which row to update - if sy-tabix has been altered in between (for example, by a nested loop over a different table, or by a READ TABLE statement that also sets sy-tabix as a side effect) before the MODIFY executes, the wrong row (or no row, if sy-tabix becomes invalid) gets updated. I would check the code between the LOOP AT and the MODIFY statement for any intervening READ TABLE (without INDEX addition) or nested LOOP that could silently overwrite sy-tabix. Another possibility is that the WHERE condition or key fields used to match the row during MODIFY (if using MODIFY itab FROM wa TRANSPORTING f1 f2 WHERE ...) don't actually match any rows due to a data type mismatch or trailing spaces/case sensitivity in a character field. I would verify by placing a breakpoint right before the MODIFY statement and checking sy-tabix, wa's actual key values, and confirming they correctly correspond to the intended row in itab at that exact point in execution.

Ranges tables (declared with SELECT-OPTIONS or a manually defined structure with SIGN, OPTION, LOW, HIGH fields) drive dynamic filtering, and unexpected results usually trace back to how rows are being added to this table. I would check whether SIGN is consistently set to 'I' (Include) or 'E' (Exclude) as intended - a common bug is defaulting to 'E' unintentionally when building the range programmatically, silently excluding instead of including data. I would check the OPTION field values ('EQ', 'BT', 'CP', 'NE', etc.) match the intended comparison - for example, using 'BT' (between) but only populating LOW and leaving HIGH initial (blank) can produce unexpected range boundaries depending on the field type. I would also check whether multiple rows were intended to be OR'd together (multiple 'I'/'EQ' rows for different values) versus mistakenly building overlapping or conflicting rows that cancel each other out logically when combined with 'E' (exclude) rows. Finally, I'd verify the internal table used in the WHERE clause (e.g., WHERE field IN lt_range) is correctly populated by displaying its content in the debugger right before the SELECT executes, comparing actual SIGN/OPTION/LOW/HIGH values against what the user's selection screen input should have produced.

The classic mistake here would be to SELECT the material description inside a loop over the 30,000 sales items, causing 30,000 individual database round trips. Instead, I would first collect the distinct material numbers from the sales item internal table (e.g., using a helper table with DELETE ADJACENT DUPLICATES after sorting, or collecting into a hashed table of just MATNR), then issue a single bulk SELECT ... FOR ALL ENTRIES IN lt_matnr_distinct into an internal table of material descriptions - checking that the distinct table isn't empty beforehand to avoid FOR ALL ENTRIES selecting the entire table. I would store this result in a hashed internal table keyed on MATNR (since we need fast unique-key lookup and the volume, 80,000 potential entries narrowed down to only the materials actually used, justifies a hashed table). Then in the main loop over the 30,000 sales items, I would use READ TABLE lt_material_hashed WITH TABLE KEY matnr = <item>-matnr to fetch the description directly from memory with near-constant time access, rather than hitting the database again. This reduces the design from potentially 30,000 database calls to a single bulk SELECT plus fast in-memory lookups.

I would look specifically for patterns where the internal table keeps growing unbounded across iterations without ever being cleared - for example, a table declared outside a loop that accumulates results across many outer-loop iterations (e.g., per company code, per period) but is never cleared or reinitialized between iterations, or a program that appends detailed line-item data into one giant table for the entire run instead of processing and clearing it in batches. I would also check for accidental duplication - a bug where the same rows get appended multiple times due to a loop structure error (e.g., a nested loop appending inside both an outer and inner loop unintentionally), causing table size to grow multiplicatively for larger data. Another common culprit is holding multiple large tables in parallel unnecessarily - for instance, keeping both a full raw-input table and a fully duplicated processed/transformed table in memory simultaneously when the raw one could have been cleared or the transformation done in-place using field symbols. I would use the debugger or SAT/memory analysis on a company code that triggers the issue to observe internal table sizes at various points in execution, and specifically watch whether any table's row count grows disproportionately compared to the actual expected business data volume for that company code.

Table expressions like itab[ key = value ] provide a concise, expression-based way to access a single row, and internally they perform essentially the same key-based lookup as a READ TABLE (using the primary or specified secondary key, with USING KEY addition if needed) - so the performance characteristics are equivalent to READ TABLE when used correctly, meaning it's still O(log n) or O(1) if reading via a sorted/hashed key, but can degrade to a linear scan if used against a standard table's non-key-optimized fields. The important pitfall to highlight is that table expressions raise a CX_SY_ITAB_LINE_NOT_FOUND exception if no matching row exists, unlike READ TABLE which simply sets sy-subrc without an exception - so code using itab[ key = value ] directly without a TRY/CATCH (or without first checking existence via a LINE_EXISTS( ) conditional expression) will dump if the row is missing, which is a common oversight when migrating older READ TABLE-based code to the newer syntax. For building tables using VALUE and REDUCE, these are generally very readable for constructing a table from a transformation of another table in a single expression, and they can actually be efficient since the compiler optimizes the construction internally, but for very complex conditional logic or multi-step transformations, forcing everything into a single VALUE/REDUCE expression can hurt readability and debuggability (since stepping through a single complex expression in the debugger is harder than stepping through an equivalent explicit LOOP), so I'd recommend using these modern constructs for genuinely simple, direct transformations, and falling back to explicit LOOP-based code when the logic involves several conditional branches or needs to be easily debuggable by other team members.

I would design a common target structure (a DDIC structure or class-local type) representing the superset of fields the consolidated result needs, and require each source-specific adapter (a method or class per source) to map its own source internal table into this common structure, appending the mapped rows into one consolidated internal table typed to the common structure - this way, the merging/consolidation logic itself only ever deals with one known structure type, regardless of how many heterogeneous sources exist or get added later. For extensibility, I would define this mapping responsibility as an interface method (e.g., IF_SOURCE_ADAPTER~GET_MAPPED_DATA returning a table of the common type) so that adding a new source in the future means implementing a new adapter class conforming to the interface, without touching the core consolidation logic at all - this follows the open/closed principle applied to internal table processing. For the consolidated table itself, I would choose the table type (sorted or hashed) based on how the merged result will be consumed downstream - for example, a hashed table keyed on a natural business key if the consolidated result needs fast lookup, or a sorted table if downstream processing needs the merged data to be presented in a defined order (e.g., for reporting). I would also build in explicit handling for potential key collisions across sources (e.g., what happens if two sources report data for the same business key - last-source-wins, error, or merge-fields logic) as a well-defined resolution rule rather than leaving it as an unhandled edge case.

If the method's IMPORTING parameter is typed with a generic table type (e.g., using a TYPE STANDARD TABLE OF interface-compatible generic type, or, more flexibly, a generic ANY TABLE or a TYPE REF TO DATA with runtime type checking via RTTS), the method needs to be written carefully because different table types support different operations - for example, you cannot rely on INDEX-based access (READ TABLE INDEX, LOOP FROM/TO) if the actual table passed at runtime happens to be hashed, since hashed tables don't support meaningful index-based access. If the method only needs to iterate all rows and read/process each one (LOOP AT itab INTO wa or ASSIGNING <fs>), this works uniformly across all three table types without issue, since basic iteration is universally supported. However, if the method needs to perform key-based lookups internally, it should not assume a specific declared key exists (since a hashed table's key might differ from what the method expects) - a more robust design is to have the method explicitly build its own internal working table (of a known, controlled type such as a hashed table keyed as needed) from the input parameter at the start, decoupling internal processing logic from whatever specific table type or key structure the caller happened to use. This adds a small upfront cost of copying/transforming the input, but greatly increases robustness and predictability of the shared method's behavior regardless of caller's internal table declaration choices.

In ABAP, assigning one internal table to another with itab2 = itab1 creates a logically independent table value, but the runtime can use table sharing/copy-on-write optimization internally so the full physical copy may not happen immediately. The important point is that once either table is modified in a way that requires independence, the runtime may need to create a physical copy of the table body. For large tables, and especially for deep/nested structures, that physical copy can become expensive in CPU and memory because the copied content can include many rows and deep components. So a senior developer should not treat itab2 = itab1 as a free operation in performance-critical code. If the second table is genuinely needed as an independently modifiable snapshot, assignment is valid. But if the data is only being read or passed to another routine, prefer passing by reference, using an IMPORTING parameter without unnecessary BY VALUE, or using a field symbol/data reference where appropriate. The design principle is: avoid unnecessary independent table copies for large internal tables, be careful with BY VALUE parameters, and use references/field symbols for read-only or alias-style processing when safe. Always balance this with clarity and data-safety, because aliases can create unintended side effects if the called code modifies the data.

ASSIGN COMPONENT idx OF STRUCTURE fails silently (does not raise a hard exception by default) if the component index idx doesn't exist in the structure - instead, sy-subrc is set to a non-zero value and the field symbol remains unassigned; if the following code doesn't check sy-subrc before using <fs>, it eventually causes an 'unassigned field symbol' dump the moment <fs> is dereferenced. Since this fails only for certain input files, the likely cause is that the component index being used (idx) is calculated dynamically (e.g., based on a column position derived from file headers or a loop counter) and for some input files the calculated index exceeds the actual number of components in wa's structure, or the structure used has fewer fields than assumed for certain file formats/variants. I would set a breakpoint right before the ASSIGN COMPONENT statement, inspect the value of idx and the actual structure of wa (number of components) for the specific failing input file, and confirm whether idx is out of bounds or pointing to a mismatched component for that particular file variant. The fix is to always check sy-subrc immediately after ASSIGN COMPONENT and handle the failure case explicitly (skip, log an error, or default the value) rather than assuming the assignment always succeeds, and to validate that the dynamic index calculation logic correctly accounts for all supported file format variants.

DELETE ADJACENT DUPLICATES COMPARING f1 f2 only removes duplicates that are physically adjacent in the table at the time of the statement - so the essential precondition is that the table must first be SORTED by exactly the same fields being compared (f1, f2), otherwise non-adjacent duplicate rows (duplicates that exist but aren't next to each other because the table isn't sorted on those fields) will not be removed, silently leaving duplicates in the result. A common pitfall is sorting the table by a different or broader set of fields than what's used in the COMPARING clause, or sorting only implicitly assuming the default key, which doesn't guarantee adjacency for the specific fields you actually want to deduplicate on. The correct approach is to explicitly SORT itab BY f1 f2 (matching exactly, and only, the fields used for deduplication comparison) immediately before the DELETE ADJACENT DUPLICATES COMPARING f1 f2 statement, ensuring true adjacency for those fields. For very large tables (hundreds of thousands of rows), this SORT plus single-pass DELETE ADJACENT DUPLICATES is efficient (O(n log n) for the sort, O(n) for the delete pass) and is generally much faster than any nested-loop-based manual duplicate detection. If the original row order needs to be preserved after deduplication (since sorting changes the order), I would keep the original row's position as a helper field, deduplicate on a sorted copy, then re-sort the deduplicated result back by that helper field to restore original ordering if truly required.

LOOP AT items WHERE vbeln = header-vbeln inside an outer loop over headers, when used on a standard table without an appropriate sorted/secondary key strategy, effectively scans the items table repeatedly for every single header row, giving roughly O(n*m) complexity - fine for small tables but very slow once both tables grow large (e.g., thousands of headers each scanning thousands of items). I would redesign this using one of two efficient patterns: first, since both tables can be sorted by VBELN, I could use a secondary sorted key on the items table (or ensure the items table itself is a SORTED table keyed by VBELN/POSNR) and replace the WHERE-based LOOP with a binary-search-based READ TABLE to find the starting row for a given VBELN, then LOOP FROM that index while VBELN matches - this uses the table's sorted nature to jump directly to the relevant rows instead of scanning the whole table each time. Alternatively, and often simpler, I would perform a single merge-style pass: sort both header and item tables by VBELN once, then loop through both tables together with synchronized pointers (advancing the item pointer as VBELN values are consumed), building the combined ALV output in one linear pass with O(n+m) complexity instead of O(n*m). Either approach dramatically reduces the number of comparisons compared to a WHERE-based LOOP repeated for every header row, and the actual choice depends on whether items also need multiple different lookup patterns elsewhere in the program (favoring secondary keys) or whether this is a one-time combined pass (favoring the merge approach).

I would design a class-level (static or instance) attribute as a hashed internal table keyed on the lookup key (e.g., a unique business key or a composite key), since hashed tables give near-constant time lookup regardless of how many entries accumulate over the object's/class's lifetime, which is essential for a cache expected to grow to potentially thousands of entries. Each cache entry would hold both the actual cached data and, ideally, a timestamp or a simple flag indicating freshness if the underlying data can change during the program's execution (to avoid serving stale data indefinitely within a single long-running session, especially for a framework class that might be reused across multiple logical operations). Before querying the database for a given key, the method would first do a READ TABLE cache_table WITH TABLE KEY key = ... and only fall through to a database read if not found (or if found but marked stale), then INSERT the newly fetched value into the hashed cache table for future calls. Pitfalls to guard against: unbounded cache growth in a very long-running batch job could itself become a memory concern if the key space is huge and mostly non-repeating, so I'd consider whether a maximum cache size or periodic clearing makes sense for that specific use case; also, in a shared/static attribute scenario, care must be taken around session/user isolation if the class is used across genuinely different logical contexts (e.g., different company codes needing different cached values for the same key) - the key definition itself may need to include a context discriminator to avoid incorrectly reusing cached data across contexts where it isn't valid.

Both approaches can achieve efficient key-based access, but they differ significantly in safety and maintainability. Using a standard table with a manual SORT followed by READ TABLE ... BINARY SEARCH requires the developer to guarantee, at every point in the program, that the table remains sorted by the exact fields used in every BINARY SEARCH read - if any later code path appends or inserts a row without re-sorting, all subsequent BINARY SEARCH reads can silently return wrong results without any runtime error, making this approach fragile especially as the program evolves and multiple developers touch it over time. Declaring the table directly as a SORTED or HASHED type moves this guarantee into the type system itself - the runtime enforces the sort order (for SORTED) or key uniqueness (for HASHED) on every insert automatically, so any violation is caught immediately rather than silently corrupting later reads. From a design perspective, I generally prefer declaring the correct table type upfront (SORTED or HASHED) whenever the access pattern is fixed and known at design time, reserving the standard-table-plus-manual-SORT-and-BINARY-SEARCH pattern only for cases where the table's required order genuinely changes dynamically during the program's execution (e.g., sorted once by field A for one phase of processing, then re-sorted by field B for a later phase) where a fixed SORTED table type wouldn't fit the changing access pattern anyway.

I would redesign the program to process the data in bounded packages rather than loading everything into one giant internal table. Using SELECT ... INTO TABLE ... PACKAGE SIZE n (a standard Open SQL addition), the database cursor returns n rows at a time into the internal table, and after processing that package (applying business logic and writing/inserting the Z-table updates, ideally also in bulk using INSERT Z_TABLE FROM TABLE lt_result rather than row-by-row), I would explicitly CLEAR (or REFRESH) the internal table before fetching the next package, ensuring memory usage stays roughly constant regardless of total data volume rather than growing to hold all 2 million rows simultaneously. I would choose a package size (e.g., 10,000 to 50,000 rows depending on record width and available memory) based on testing, balancing fewer database round trips (favoring larger packages) against memory footprint (favoring smaller packages). I would also add a COMMIT WORK (or equivalent database commit for the Z-table inserts) after each package to avoid holding a very long-running single LUW, and include a simple checkpoint (e.g., logging progress or the last processed key) so the job could be restarted from a reasonable point if it fails partway through, rather than needing to reprocess all 2 million records from scratch.

First, always choose the internal table type based on the actual access pattern rather than defaulting to standard tables out of habit: use hashed tables for large, frequently-looked-up-by-unique-key reference/lookup data; sorted tables when data must remain ordered and key-based reads are frequent; standard tables for append-heavy or predominantly index-based processing. Second, never use nested LOOP AT ... LOOP AT ... (or LOOP AT ... WHERE inside another loop) without a key-based or sorted/hashed backing - this pattern's quadratic complexity is the single most common recurring root cause of production performance escalations, and should always be replaced with key-based READ TABLE (via secondary keys if needed) or a merge-style single pass over sorted tables. Third, avoid unnecessary deep copies (itab2 = itab1) for large tables when a field symbol or reference would suffice, particularly inside methods/subroutines that only need read access. Fourth, be precise about BINARY SEARCH preconditions - either use it only immediately after an exact matching SORT, or better, avoid the risk entirely by declaring the table as SORTED/HASHED from the start so the runtime enforces correctness rather than relying on developer discipline. Fifth, for high-volume batch processing, bound memory usage explicitly through package-based processing (PACKAGE SIZE, periodic CLEAR) rather than accumulating unbounded data in memory across a long-running job. I would enforce these principles through targeted code review checklist items and, where feasible, custom Code Inspector (SCI/ATC) checks that specifically flag nested LOOP AT WHERE patterns and unguarded BINARY SEARCH usage, since relying purely on developer awareness doesn't scale consistently across a team.