performance on Abapinho

Pass internal tables by value is good

Mon, 11 Jul 2016 09:00:21 +0000

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

Mon, 25 Jan 2016 09:00:47 +0000

This is how internal tables used to be declared:

DATA: itbl TYPE TABLE OF bkpf.

DELETE vs CLEAR vs REFRESH vs FREE

Mon, 27 Jul 2015 09:00:01 +0000

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

Mon, 18 May 2015 09:00:13 +0000

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

Thou shalt use TRANSPORTING NO FIELDS

Mon, 09 Mar 2015 09:00:02 +0000

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

Tue, 25 Nov 2014 09:00:13 +0000

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 *

Thu, 04 Sep 2014 11:25:03 +0000

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

Thu, 24 Jul 2014 09:00:50 +0000

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

Mon, 26 May 2014 09:00:03 +0000

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

Mon, 10 Jun 2013 09:00:27 +0000

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

Mon, 01 Apr 2013 16:11:22 +0000

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

Mon, 28 Nov 2011 11:37:25 +0000

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

Sat, 02 Jul 2011 12:25:03 +0000

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

Taking a nap

Fri, 17 Jun 2011 11:43:28 +0000

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!

Tue, 24 May 2011 09:00:41 +0000

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

LOOP FROM INDEX

Thu, 10 Mar 2011 12:15:12 +0000

It’s very easy to get tied up in knots where performance is concerned when you’re working with internal tables – especially when they’re getting really big. In fact these problems often only arise after a few months, when the tables tend to grow as time goes by. For example, when you’re looping two tables, one of headers and another of entries, do you do this? LOOP AT itab1 ASSIGNING <fs1>. LOOP AT itab2 ASSGNING <fs2> WHERE field1 = <fs1>-field1.

SAT – The new execution analysis tool

Wed, 16 Feb 2011 14:31:40 +0000

Since I was small I have been using the SE30 transaction for two different things: To analyze a (normally standard) program I don’t know in order to find out what functions it uses, what BADIs it offers, etc; To analyze a program of mine to search for performance problems. The simple truth is that the SE30 transaction is a total mess. It’s extremely limited and inflexible and it’s useless for any more complex analysis.

Macros - Velocidade de ponta

Wed, 16 Sep 2009 02:37:52 +0000

Normalmente quando há um pedaço de código que pretendemos reutilizar várias vezes, transformamo-lo numa sub-rotina que pode depois ser invocada repetidamente. Embora a SAP não saiba estruturar o seu próprio código, ainda assim, o ABAP, coitadinho, permite-o. E até disponibiliza várias alternativas para modularizar o código. Eu conto quatro alternativas que listo aqui, da mais rígida para a mais flácida: METHOD, FUNCTION, FORM, DEFINE. Se os 3 primeiros são já familiar de todos, o último - DEFINE - quase ninguém usa. O DEFINE permite definir macros em ABAP. E o que são macros? São sub-rotinas aparentes.

Aparentes porquê?

READ TABLE blablabla TRANSPORTING NO FIELDS

Thu, 20 Aug 2009 04:51:19 +0000

Por vezes ao fazer READ TABLE a uma tabela interna queremos apenas verificar se um determinado registo existe, e não nos preocupamos com os dados retornados. Algo tipo: READ TABLE lt_kna1 INTO wa_kna1 WITH KEY kunnr = l_kunnr. CHECK SY-SUBRC = 0. Ora já que a estrutura WA_KNA1 não vai ser necessária de qualquer forma, mais vale não a usar, usando antes a opção TRANSPORTING NO FIELDS: READ TABLE lt_kna1 TRANSPORTING NO FIELDS WITH KEY kunnr = l_kunnr.