Tag > performance
Supported by
Supported by Inetum

Pass internal tables by value is good

images/thumbnail.jpg - Thumbnail

When a method returns a value as a RETURNING parameter this is always done by value and not by reference. Several of my methods return internal tables, some of them quite large. It always worried me the idea that, since it’s being passed by value, ABAP would be returning a copy of the internal table, impacting both performance and the program’s used memory.

Fortunately, I recently learned that this is not​ a problem.

Internal table secondary indexes

images/thumbnail.jpg - Thumbnail

This is how internal tables used to be declared:

DATA: itbl TYPE TABLE OF bkpf.

DELETE vs CLEAR vs REFRESH vs FREE

images/thumbnail.jpg - Thumbnail

DELETE CLEAR REFRESH FREE

These are different ways of deleting all data from an internal table. They look the same. But they aren’t.

Teach ABAP to juggle

images/thumbnail.jpg - Thumbnail

What can be done when a night is not enough to complete the daily processes?

Thou shalt use TRANSPORTING NO FIELDS

images/thumbnail.jpg - Thumbnail

Many times we do READ TABLE itbl or LOOP AT itbl just to do a CHECK SY-SUBRC = 0. In these cases, the actual data read is not needed. For these cases always use TRANSPORTING NO FIELDS. This way is faster and avoids having to declare a target structure.

INNER JOIN vs FOR ALL ENTRIES vs artificial RANGES

images/thumbnail.jpg - Thumbnail

Since data operations are much more optimized in the database server than in ABAP, it is always better to use the first as much as possible. FOR ALL ENTRIES should only be used when INNER JOIN doesn’t give us what we need or is not possible (like with BSEG for example). Artificial ranges are also a possible alternative to FOR ALL ENTRIES but be careful not to reach the SQL parser limit.

Thou shalt not SELECT *

images/thumbnail.jpg - Thumbnail

Always try to select only the fields you’ll need. Selecting others is a waste of resources. Exception made for the use of FM *_SINGLE_READ because, even though these do select all fields, since they cache the data, they are still faster when used multiple times for the same key. If you just want to check if a record exists, select just one field, if possible the one you’re using as criteria to avoid declaring an extra variable.

Thou shalt use FIELD-SYMBOLs instead of working areas

images/thumbnail.jpg - Thumbnail

READ TABLE itbl ASSIGNING is always faster than READ TABLE itbl INTO wa. Besides, when making changes to internal tables, not only it doesn’t require the explicit MODIFY but it also does away with the auxiliary TABIX variable. The only situation in which a working area is better is when adding new lines to an internal table. Some people contend that working areas should still be used when no changes are to be made to the data.

SELECT within SELECT

images/thumbnail.jpg - Thumbnail

ABAP programmers don’t explore the possibilities of SQL, probably for historical reasons. There are many who instead of using INNER JOINs still think it’s faster to do several SELECTs for internal tables and then process the data in ABAP. But the truth is that even if there are exceptions, the rule is: the lower the number of accesses to the database, the better the performance. And it makes sense because, after all, they were written explicitly for this; relational databases are much more adept at processing relational data than an ABAP program.

There are of course things that, due to their complexity, cannot be done with a simple INNER JOIN. Nevertheless, some of these things can be done in a single SELECT.

With many fields avoid INTO CORRESPONDING FIELDS

images/thumbnail.jpg - Thumbnail

I have already advised here that, in tables with many fields, it’s always recommended to avoid using SELECT *, you must always select, explicitly, only the necessary fields.

But I didn’t warn you that there’s yet another optimisation worth making: avoid INTO CORRESPONDING FIELDS OF TABLE.

SORTED instead of STANDARD in the cache tables

images/thumbnail.jpg - Thumbnail

Some time ago I wrote a post here showing the advantages of using internal tables with defined indexes instead of simple STANDARD tables. Confession: that habit is so ingrained that since then, almost all the internal tables I have created have continued to be STANDARD TABLE. It’s very common to create internal tables to cache data that I know I’ll often use inside LOOPS to avoid having to SELECT SINGLES inside them.

Partial Analyses in SE30

images/thumbnail.jpg - Thumbnail

Obviously you already know the SE30 transaction (run time analysis) and obviously you use it often to analyse standard programs and to discover tables, functions, BADIs and similar contained within them. But if you are like me, then you have a love-hate relationship with this transaction – on the one hand you love it because it enables you to see the guts of a program without having to debug it, yet on the other hand you hate it because normally the list of guts tends to have thousands of lines and becomes unmanageable.

LOOP ASSIGNING instead of LOOP INTO

images/thumbnail.jpg - Thumbnail

In the beginning there was INTO. Actually, in the beginning it was not even INTO.

Taking a nap

images/thumbnail.jpg - Thumbnail

Whatever the case, it is necessary to put a program to sleep. And, as with almost everything else, there are several ways to do this, some better than others. The most standard way to do this in ABAP is as follows: WAIT UP TO 10 SECONDS. The advantage of WAIT UP TO N SECONDS is that the process is freed up during these 10 seconds, thereby making it available for those who want it.

On your marks, get set, go!

images/thumbnail.jpg - Thumbnail

Ladies and gentlemen, boys and girls, the race is about to begin.

Introduction

The four competitors are as follows. They are 4 internal tables, of different races and creeds, which will fight for the athletics title of speed LOOP. Here they are:

Competitor 1: DATA: LT_ITEM TYPE TABLE Competitor 2: DATA: LT_ITEM_HASHED TYPE HASHED TABLE Competitor 3: DATA: LT_ITEM_SORTED TYPE SORTED TABLE Competitor 4: DATA: LT_ITEM TYPE TABLE + INTO INDEX