2010 Mar 09 6:21 AM
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
2010 Mar 09 1:51 PM
> 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
2010 Mar 09 6:24 AM
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
2010 Mar 09 9:58 AM
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
2010 Mar 11 6:05 AM
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
2010 Mar 09 1:51 PM
> 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
2010 Mar 09 4:15 PM
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
2010 Mar 09 4:54 PM
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.
2010 Mar 10 8:20 AM
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
| User | Count |
|---|---|
| 3 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |