topic Re: Performance with field symbols in Application Development and Automation Discussions

Performance with field symbols

Former Member — Fri, 12 Nov 2010 07:38:05 GMT

Hi,

Can someone tell me if performance is better when using field symbols rather than work area.

Example, In loops we use Loop at table <tab1> into <wa> where var1 = var2

Will it help using field symbols, when the internal table <tab1> has large number of entries

Thanks!

Re: Performance with field symbols

SuhaSaha — Fri, 12 Nov 2010 07:49:40 GMT

Hello,

Imho using Field-Symbols in LOOP .. WHERE won't improve the performance significantly.

LOOP ... WHERE is optimised for SORTED & HASHED tables. Read the SAP documentation for more details: [http://help.sap.com/abapdocu_70/en/ABAPLOOP_AT_ITAB_COND.htm#&ABAP_ADDITION_3@3@].

BR,

Suhas

Re: Performance with field symbols

Former Member — Fri, 12 Nov 2010 09:36:29 GMT

Hi Suhas,

I found something which says field symbols might increase efficiency -[http://wiki.sdn.sap.com/wiki/display/Snippets/ImprovenestedloopperformancewithABAP|http://wiki.sdn.sap.com/wiki/display/Snippets/ImprovenestedloopperformancewithABAP]

Re: Performance with field symbols

ThomasZloch — Fri, 12 Nov 2010 10:17:29 GMT

It is only a minor factor, one should focus on the major issues first (e.g. access to large DB or internal tables without key support). My own (not scientific) measurements showed about a 10% performance gain for large loops assigning field symbols over the same loop into work areas, because less data has to copied in memory. The effect might be a little larger if you are changing values in the work area, because the changes then have to be copied back to the table.

Now this measurement was only for this very loop, if your program does other things as well, the overall impact can be neglected most of the time.

Thomas

Re: Performance with field symbols

Former Member — Fri, 12 Nov 2010 14:17:01 GMT

Please see [Performance - what will kill you and what will leave you with only a flesh wound|/people/rob.burbank/blog/2006/11/16/performance--what-will-kill-you-and-what-will-leave-you-with-only-a-flesh-wound]

Rob

Re: Performance with field symbols

SuhaSaha — Sun, 14 Nov 2010 05:33:42 GMT

Hello Sim,

If you read the tip carefully you'll find that Ivan has mentioned that using field-symbols will improve performance when "LOOP'ing over large internal tables" & that too (as Thomas has mentioned) is in the range of 10%.

In these kind of scenarios i always prefer doing a runtime analysis of the code rather.

BR,

Suhas

Re: Performance with field symbols

Former Member — Mon, 15 Nov 2010 02:41:40 GMT

Internal tables are huge. I basically have 3 loops Loop1 with 602 entries, Loop 2 with 903 entries and Loop3 with 14448 entries and loop1 looping loop2 which in turn loops loop3

I also heard about some BASIS transaction which helps bufeering loops in sections. Not sure about its exact functions. Does anyone have any idea about something like that?

Re: Performance with field symbols

ThomasZloch — Mon, 15 Nov 2010 08:24:24 GMT

In your scenario it is much more important that the tables in loop2 and loop3 are declared as SORTED tables and you are using a leading part of the table key in the WHERE conditions. If you use the full table key, you can also try using HASHED tables.

Also look into maybe changing the program logic, sometimes you can rearrange the loops so that the biggest table is loop1, and the smaller ones are accessed inside the outer loop. Maybe you can even change the way the tables are being filled, e.g. by switching from FOR ALL ENTRIES to a JOIN select statement, and even reduce the nesting level.

Always max out the possibilities of clean programming before adjusting any system settings or adding hardware.

Thomas

Re: Performance with field symbols

ravi_lanjewar — Mon, 15 Nov 2010 12:05:32 GMT

Hi,

Fields symbols gives better performance over the work area.

I have tested the result for modify the internal table content with 100 entries with fields symbols and work area.


LOOP AT ITAB INTO WA.
    WA-FLAG = 'X'.
    MODIFY ITAB FROM WA.
ENDLOOP.

Runtime: 755 microseconds


LOOP AT ITAB ASSIGNING <WA>.
 <WA>-FLAG = 'X'.
ENDLOOP.

Runtime: 91 microseconds

For accessing the internal table content with 100 entries with fields symbols and work area.


LOOP AT ITAB INTO WA.
ENDLOOP.

Runtime:327 microseconds


LOOP AT ITAB ASSIGNING <WA>.
ENDLOOP.

Runtime: 83 microseconds

So, It is clear that fields symbols more efficient over the work area not only the 10% but more than 10% (i.e approximatly 30% to 70%) depends only where you are modify content or accessing the content.

But, Here is more important role is where condition which is not consider here.

When you are putting the where condition then only modification and access the row of internal table is also depends upon the type of internal table (i.e index, Hashed or sorted)

If you put exactly key or index fields of internal table with fields symbols.

Fields symbols improve the performance 1/3rd over the work area whatever the where condtion.

In your condition you are using the nested internal table you can define the the proper internal table for it. (ie standard, hashed or sorted)

How to used the different internal table type and there performance ? we discuss here many time.

Re: Performance with field symbols

ThomasZloch — Mon, 15 Nov 2010 12:13:00 GMT

Can you run this for 100,000 entries please and not only 100, and then draw conclusions?

I'm really interested in comparing results, but with just 100 you have too much internal overhead, I'm afraid.

Also please use MODIFY ITAB FROM WA TRANSPORTING FLAG for a fair comparison (depending how many fields your ITAB has, please also disclose the structure).

Thomas

Re: Performance with field symbols

SuhaSaha — Mon, 15 Nov 2010 12:15:59 GMT

Fields symbols improve the performance 1/3rd over the work area whatever the where condtion.

Too much generic to digest. ~~Definitely FS have advantage over WA, but 1/3rd is way too much.~~

I take my words back, i just compared these 2 code snippets & found otherwise:

data: itab type standard table of t001.
field-symbols: <wa> type t001.

select * from t001 into table itab.

loop at itab assigning <wa>.
endloop.

This took 20 secs to executes whereas:

data: itab type standard table of t001,
wa type t001.

select * from t001 into table itab.

loop at itab into wa.
endloop.

took 17 secs.

Dunno why :-S

BR,

Suhas

Re: Performance with field symbols

ravi_lanjewar — Mon, 15 Nov 2010 12:46:57 GMT

Hi Suhas,

Write your code following way and check the difference, In above case I was considering the internal table not select SQL


data: F1 type t,
      F2 type t,
      f3 TYPE t.

data: itab type standard table of t001,
      wa type t001.

field-symbols: <wa> type t001.

select * from t001 into table itab.

get RUN TIME FIELD f1.
loop at itab ASSIGNING <wa>.
endloop.
get RUN TIME FIELD F2.

f3 = f2 - f1.

Write f3.

There is approximatly 50% difference in time.

Re: Performance with field symbols

SuhaSaha — Mon, 15 Nov 2010 13:00:27 GMT

Hello Ravi,

My bad! Should have removed the SQL part from the runtime analysis.

I checked with this code snippet in SE30:

Sample1: This took 210.142 microseconds to execute.

DATA: itab TYPE STANDARD TABLE OF char1,
      wa TYPE char1.

FIELD-SYMBOLS: <wa> TYPE char1.

DO 1000000 TIMES.
  wa = 'A'.
  APPEND wa TO itab.
ENDDO.

LOOP AT itab INTO wa.
ENDLOOP.

Sample2: This took 208.650 microseconds to execute.

DATA: itab TYPE STANDARD TABLE OF char1,
      wa TYPE char1.

FIELD-SYMBOLS: <wa> TYPE char1.

DO 1000000 TIMES.
  wa = 'A'.
  APPEND wa TO itab.
ENDDO.

LOOP AT itab ASSIGNING <wa>.
ENDLOOP.

How do you explain your ~30% increment using FIELD-SYMBOLS? I don't see it.

BR,

Suhas

Re: Performance with field symbols

Rui_Dantas — Mon, 15 Nov 2010 14:19:40 GMT

In fact it's true that a LOOP ASSIGNING can be like 80% faster than a LOOP INTO.

However, just the loop itself doesn't take that long: what really consumes time is to find the correct entries.

If you have some something like:

LOOP AT table INTO wa.

It won't take that long, even if table has millions of lines. It is true that you can reduce the time by changing to LOOP AT ASSIGNING, but you will be optimizing something that is not that bad to start with. It is probably not what is causing the performance problems your users are complaining about.

However, if you have:

LOOP AT table INTO wa.
   LOOP AT table2 INTO wa WHERE ...

Then that will take long because the inner loop is made millions of times. And for that case you will have to use SORTED tables, changing to FIELD-SYMBOLS won't make that much of a difference.

Rui Dantas

Re: Performance with field symbols

SuhaSaha — Tue, 16 Nov 2010 04:34:52 GMT

Hello Rui,

If you see the code snippets i have used to compare LOOP INTO v/s LOOP ASSIGNING i can't see the 80% increment you're talking about.

My question to Ravi & you will now be: Under what circumstances will LOOP ASSIGNING be 80% faster than LOOP INTO? Please enlighten me with a few code snippets.

BR,

Suhas

Re: Performance with field symbols

ThomasZloch — Tue, 16 Nov 2010 08:14:07 GMT

It will largely depend on the length of the structure i.e. amount of data that is being copied in memory or not. In one of your above examples, you had a structure of just one character, so almost no gain there.

I don't have my dev system today, so I can chime in with my own new measurement tomorrow.

Whatever the outcome, my view is, when designing new programs one might as well chose field symbols right away, however it is usually not worth the effort to change existing programs just for the small performance improvement.

Thomas

Re: Performance with field symbols

Former Member — Tue, 16 Nov 2010 10:24:16 GMT

In my case, the loops using where are satisfying 7-8 lines from the internal table. This happens for all the 3 loops. i.e I do not get a unique row from any of the loop. In that case how do I use hashed table/sorted table?

Re: Performance with field symbols

ravi_lanjewar — Tue, 16 Nov 2010 12:26:49 GMT

Hi Suhas,

I Check the 2 different program

Program1


data: F1 type t,
      F2 type t,
      f3 TYPE t.

data: itab type standard table of BSEG,
      wa type BSEG.

field-symbols: <wa> type BSEG.

select * up to 100000 ROWS into table itab FROM BSEG.

get RUN TIME FIELD f1.
perform process_data.
get RUN TIME FIELD F2.

f3 = f2 - f1.

Write f3.
form PROCESS_DATA .
loop at itab ASSIGNING <wa>."into wa."
endloop.
endform.

Program2


data: F1 type t,
      F2 type t,
      f3 TYPE t.

data: itab type standard table of HRP1001,
      wa type HRP1001.

field-symbols: <wa> type HRP1001.

select * up to 100000 ROWS into table itab FROM HRP1001.

get RUN TIME FIELD f1.
perform process_data.
get RUN TIME FIELD F2.

f3 = f2 - f1.

Write f3.
form PROCESS_DATA .
loop at itab into wa. "ASSIGNING <wa>. ""
endloop.
endform.

Result

Program fields symbols Work Area %Percentange variation

Program1 126426 697062 18%

Program2 77128 195429 39%

So, Factor which is affect the column in internal table and alos table rows also.

I think it will not improve the performance exactly 1/3 but it varies depending on different circumtances from 10% to 70%.

If you are modifing the internal table content then fields-symbol give more than 50% faster over work area.

I think this will help you out.

Re: Performance with field symbols

Rui_Dantas — Tue, 16 Nov 2010 14:20:51 GMT


> My question to Ravi & you will now be: Under what circumstances will LOOP ASSIGNING be 80% faster than LOOP INTO? Please enlighten me with a few code snippets.
> Suhas

Hi Suhas,

Go to SE38, Environment -> Examples -> Performance Examples.

Them choose the one relevant for our discussion:

Internal Tables -> Using the Assigning Command -> Modifying a set of lines directly.

And measure it. What do you get?

In my system I get 190 vs 35 (or a little over 80% improvement).


> ... my view is, when designing new programs one might as well chose field symbols right away, however it is usually not worth the effort to change existing programs just for the small performance improvement.
> Thomas

I completely agree with Thomas: use field-symbols in new programs (why not?) but don't expect them to solve performance problems in existing programs.

Rui Dantas

Re: Performance with field symbols

Rui_Dantas — Tue, 16 Nov 2010 14:23:40 GMT


> In my case, the loops using where are satisfying 7-8 lines from the internal table. This happens for all the 3 loops. i.e I do not get a unique row from any of the loop. In that case how do I use hashed table/sorted table?

You can't use hashed tables (they require access by a unique key) but you can and should use sorted tables. Just make sure you are reading by one or more of the first (leftmost) key fields.

Rui Dantas