I'm currently learning ABAP and can anyone explain why t_table2 = t_table1
is significantly faster than APPEND LINES OF t_table1 TO t_table2
?
t_table1, t_table2 are internal tables
I'm currently learning ABAP and can anyone explain why t_table2 = t_table1
is significantly faster than APPEND LINES OF t_table1 TO t_table2
?
t_table1, t_table2 are internal tables
In addition to the answers by Zero and Cameron Smith, there's also a concept called "table sharing" (AKA "copy-on-write") which delays the copy until any of the source or target internal table is changed.
If I simplify a lot, one could represent it like the assignment like a copy of 8 bytes (the address of the source internal table). Anyway, most of the time, one of the 2 internal tables will be changed (otherwise, why would there be a copy in the code!) so the final performance is often almost the same, it's just that sometimes there's a benefit because of some code "badly" written.
I can't say this is a full reason (there's probably more going on behind the scenes that I don't know), but some of the reasons definitely include the following. A thing to note here: on small to medium data sets the difference in speed is negligible.
t_table2 = t_table1
just takes all of data and copies it, overwriting t_table2
( it does NOT append
). In some cases (such as when passing parameters) the data does not even get copied. The same data may be used and a copy will only be produced if a t_table2 needs to be changed.
APPEND LINES OF t_table1 TO t_table2
is basically a loop, which appends records row by row.
The reason I mention the append
is because overwrite of a table can be as simple as copy data (or data reference in rare cases) from a
to b
, while append performs checks whether or not the table is sorted, indexed and such. Even if the table is in its most basic state, append of an internal table is a slightly more complex procedure than an overwrite of a variable.
When you define an internal table with DATA, the kernel allocates more than one row's space in the memory, so they are stored togehter. Also every time you fill these rows, again a bigger batch will be booked.
You can see this in memory dumps, in this case 16 rows would have been allocated:
When you copy with APPEND LINES OF
, the kernel copies line-by-line.
When you just say itab1 = itab2
, it gets copied in blocks.
Based on the information above, you might think line-by-line is 16 times slower. It is not, in practice, depending on row width, number of lines, kernel version and many other things it is just 10-30% slower.