Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

abap work area

Former Member
0 Likes
2,091

Hi,

many times it is advised to use work areas while defining internal table instead of header line or using default work area. so i want to know how defining separate work area improves the performance? is it the memory or cpu perfomance is improved by defining separate work area?

Regards,

Santosh

1 ACCEPTED SOLUTION
Read only

Former Member
0 Likes
1,208

> This technique is never slower than using a work area or header line, if you have long table structures with many fields, it is > up to 10 times faster.

this is incorrect, for LOOPs the overhead is very small, but for reads it can be considerable.

You should really expect only a benefit, if you use ASSIGNING with rather width tables and deep structures!

Work areas should be used because there was a lot of confusion between the header lines and the whole tables.

Much more than the ASSIGNING is the fast search on internal tables, i.e. BINARY SEARCH or the sorted or hashed tables which use a primary key.

Siegfried

Hi,

many times it is advised to use work areas while defining internal table instead of header line or using default work area. so i want to know how defining separate work area improves the performance? is it the memory or cpu perfomance is improved by defining separate work area?

Regards,

Santosh

7 REPLIES 7
Read only

Former Member
0 Likes
1,208

Hi,

header lines are not allowed in oo context, there is not influence on performance comparing header lines and work areas.

If you concern about performance, use field-symbols, not work areas.

Regards,

--

Przemysław

Read only

Clemenss
Active Contributor
0 Likes
1,208

Hi Santosh,

you will have no performance improvement when using work areas as a replacement for implicit header lines of tables with header lines. Because implicit header lines have the same name as the internal table itself, you will always get a warning in extended syntax check. For this reason tables with header lines are forbidden in OO context.

If you LOOP AT an internal table, the current record is always copied into the header line or work area. You will gain performance using field-symbols:

DATA:
  lt_t001 TYPE TABLE OF t001.
FIELD-SYMBOLS:
  <t001> TYPE t001.
...
LOOP AT lt_t001 ASSIGNING <t001>.
  WRITE: / <t001>-bukrs.
ENDLOOP.

This is just an example. Here the current record in the loop is assigned to field-symbol <t001>. That means nothing is copied, just the memory address is assigned to the field-symbol.

This technique is never slower than using a work area or header line, if you have long table structures with many fields, it is up to 10 times faster.

So my suggestion is to get used to field-symbols and internal tables without header lines and forget work areas.

Regards,

Clemens

Read only

Former Member
0 Likes
1,208

One can use field symbols but has to be careful with it.

When you use field symbols and pass values of one field symbol to other field symbols you have to assign the latter field symbol with a work area of same type as field symbol and also have to clear the work area since whatever you pass to field symbol gets stored in work area also.

Have a look of the below code.


 LOOP AT i_a910 ASSIGNING <fs_a910>.
    CLEAR wa_cond.
    ASSIGN wa_cond TO <fs_cond>.
    MOVE-CORRESPONDING <fs_a910> TO <fs_cond> .
APPEND <fs_cond> TO i_cond.

Edited by: ASINGH512 on Mar 11, 2010 7:06 AM

Read only

Former Member
0 Likes
1,209

> This technique is never slower than using a work area or header line, if you have long table structures with many fields, it is > up to 10 times faster.

this is incorrect, for LOOPs the overhead is very small, but for reads it can be considerable.

You should really expect only a benefit, if you use ASSIGNING with rather width tables and deep structures!

Work areas should be used because there was a lot of confusion between the header lines and the whole tables.

Much more than the ASSIGNING is the fast search on internal tables, i.e. BINARY SEARCH or the sorted or hashed tables which use a primary key.

Siegfried

Read only

0 Likes
1,208

Hi Sigi,

we talked about loops. I just said that you are never slower using assigning.

his is incorrect, for LOOPs the overhead is very small, but for reads it can be considerable.

Can you please elaborate on read overhead?

Regards,

Clemens

Read only

SuhaSaha
Product and Topic Expert
Product and Topic Expert
0 Likes
1,208

Hey Guys,

Since the discussion on header lines v/s work area is up again, may i use this opportunity to ask a small question. (Dear mods, hope this is ok)

In my basic ABAP training we were told header line actually holds some memory area of its own but a work area does not. Is this reason enough for not using header lines ?

BR,

Suhas

PS: For me the main reasons for discarding header lines would be: a. non-compatibility in OO context, b. confusion between main table & header lines.

Read only

0 Likes
1,208

Hi,

in the BC400 training there is suggestion, that is it better to use header lines instead of explicit work areas, because of:

- shorter form of instructions (APPEND itab instead of APPEND wa TO itab; LOOP AT, etc.)

- you have one variable (table body and header), not two

but you have to concern, does system use table header or table body in specified instructions.

Of course, in ABAP Objects you are not allowed to use header lines.

In the BC402 there is suggestion, that you should use field-symbols rather than header lines - it is faster.

I think it is quite easy to distinguish if instruction uses table body or header:

- some instructions use both of them - i.e. APPEND itab. LOOP AT itab.

- in all other situations, table header is used by default, so if you want to use body, just write: itab[]

- I try to place [] everywhere in the code, when I want to mark that I am using a table (even if it is not necessary),

like:


SELECT * 
  INTO TABLE itab[]
  ...

CLEAR itab[].

CALL FUNCTION ...
  IMPORTINT
    it_tab = itab[]
  TABLES
    tab = itab[].

Currently I am using field-symbols (mainly).

If I write some simple, low-importantance program - I choose table header lines - it is easier and faster to write.

Regards,

--

Przemysław