ABAP Pointers

According to Zevolving, work areas seem to have slightly better performance over pointers.

Clients always want faster ABAP programs. And for a good reason too. If programs work faster, less time is wasted and the overall productivity would be increased – in theory at least. In practice, it might mean “More time to loaf on Facebook!” to some employees but hey, it’s their own Karma – they can mess it up if they want to. Our purpose is to love others and give them more time – the most scarce and irreplaceable resource of nowadays – by making our ABAP programs faster.

One of the methods to speed things up is to have faster internal table operations. In classic ABAP, we tend to use header lines or work areas to access a certain line in an internal table. However, this method has a high performance cost. In this article, I will show you how to use pointers in internal table operations for much faster execution.

Here is a simple loop written with classic ABAP:

data: gt_itab type table of ztable,
      gs_itab type ztable.

perform read_ztable.

loop at gt_itab into gs_itab.
 write:/ gs_itab-matnr.
 endloop.

Technically, that works. However; if you have 5.000 records in gt_itab, it means that you are copying the contents of each record into gs_itab once – 5.000 times in total. You can avoid that performance cost simply by using a pointer instead:

data: gt_itab type table of ztable,
      gr_itab type ref to ztable.

perform read_ztable.

loop at gt_itab reference into gr_itab.
  write:/ gr_itab->matnr.
endloop.

In this approach, no data is copied. The pointer gr_itab simple points to a line within gt_itab. We can directly access a field using the operator -> . Therefore, it is *much* faster. Pointers can be used with other table operations as well; let’s see some examples.

You can “read table” using pointers:

read table gt_itab index 1 reference into gr_itab.
check sy-subrc eq 0.
write:/ gr_itab->matnr.

You can “append” using pointers:

append initial line to gt_itab reference into gr_itab.
gr_itab->matnr = 'M123'.

Please note that we don’t need to use the command “modify” any more. When we modified gr_itab->matnr , we modified the actual “cell” within the internal table directly. Very unlike and much faster than using a work area.

Don’t get too creative and use the “append initial line” all over the place though.This doesn’t work on ITAB’s with hashed / sorted keys for obvious reasons. If it’s not too obvious for you, stick to my blog – I might be talking about hash / sort stuff in my upcoming posts. Let’s stick to our subject for now.

Following the same logic, it is also possible to access & modify internal table “cells” directly with loop & read commands:

read table gt_itab index 1 reference into gr_itab.
if sy-subrc eq 0.
   gr_itab->matnr = 'M123'.
endif.

loop at gt_itab reference into gr_itab 
where werks eq p_werks.
 gr_itab->flag = 'X'.
 endloop.

If you need to access the entire line (like a regular work area), you can easily achieve that by using the star token:

“ Set pointer
read table gt_itab index 1 reference into gr_itab.
check sy-subrc eq 0.

“ Example 1: Move-Corresponding
 move-corresponding gr_itab->* to gs_temp.

“ Example 2: Use as parameter
 call method show_itab_lin
 exporting
 im_s_line = gr_itab->*.

Did you notice that I always “check sy-subrc” after a table operation? That has a good reason in terms of stability. If, for example, gt_itab is empty and gr_itab is not assigned; it means that a nice big short dump is coming your way. Check the following example:

refresh gt_itab.
read table gt_itab index 1 reference into gr_itab.
gr_itab->matnr = 'M123'. " Here comes the short dump!!!

To avoid that, you can either check sy-subrc, or check the reference variable directly.

refresh gt_itab.

“ Method 1
 read table gt_itab index 1 reference into gr_itab.
 if sy-subrc eq 0.
 gr_itab->matnr = 'M123'.
 endif.

“ Method 2
 read table gt_itab index 1 reference into gr_itab.
 if gr_itab is not initial.
 gr_itab->matnr = 'M123'.
 endif.

Sometimes, you “read table” just to check if there is a corresponding record or not. You don’t actually need the data in the internal table. In that case, you can increase the performance even more by not even using a pointer. Check the following examples:

read table gt_itab transporting no fields 
                   with key matnr = lv_matnr.
check sy-subrc eq 0.

Same applies to loops as well:

loop at gt_itab transporting no fields 
where werks eq p_werks.
   add 1 to lv_count.
endloop.

Pointers will help you write faster ABAP programs – and impress your friends as well. Seniors will surround you drooling & asking how you managed to turn a turtle-program into a race rabbit; and debugging juniors will go to the corner in tears, wondering why & how you managed to avoid the “modify” command and still changed the data. Be nice, humble, and share the know-how. Otherwise, you would be serving your ego and not the universe; which ultimately leads to disconnection (bad Karma alert).

Feel free to post a comment if you have questions.

Advertisement