Using Pointers to Increase ABAP Performance

1464-ppt

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.

2 thoughts on “Using Pointers to Increase ABAP Performance

  1. A small doubt What is the advantage Over field symbols using these Ref . Please put some light on it

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s