Application Development 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: 

Performance with field symbols

former_member215781
Active Participant
0 Kudos

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!

1 ACCEPTED SOLUTION

ravi_lanjewar
Contributor
0 Kudos

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.

29 REPLIES 29

SuhaSaha
Advisor
Advisor
0 Kudos

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

0 Kudos

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]

0 Kudos

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

0 Kudos

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

0 Kudos

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?

0 Kudos

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

Former Member
0 Kudos

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

ravi_lanjewar
Contributor
0 Kudos

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.

0 Kudos

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

0 Kudos

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

0 Kudos

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.

0 Kudos

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

0 Kudos

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

0 Kudos

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

0 Kudos

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

0 Kudos

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.

0 Kudos

>

> 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

0 Kudos

OK, my dev system is back, and I must admit I fell into the same trap as Suhas, my previous measurements included the select statement to filll the tables.

Without it, the gain of using "ASSIGNING <fs>" over "INTO wa" is around 50% for 500,000 entries in a table with 5 fields and some manipulation inside the loop. The gain will be more or less depending on the row size and extent of manipulation.

But again, normally you don't have just these loops (the internal table needs to be filled somehow after all), so the entire program execution time might be reduced only by 10% or even less, depending on circumstances.

Thomas

0 Kudos

Hello Rui,

First of all i think i am being misunderstood.

I agree with Thomas 100% (which i usually do) that in new developements Field-Symbols is the technique to use. But definitely they are not the major cause of the performance issues we see in existing programs

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

And measure it. What do you get?

This is what i use all the times

Cheers,

Suhas

0 Kudos

Hi Suhah,

Yes, it's true, something here is not being understood.

>

> Under what circumstances will LOOP ASSIGNING be 80% faster than LOOP INTO? Please enlighten me with a few code snippets.

> Suhas

I sent you the menu path in SE38 for the performance examples, where you have the exact scenario we are discussing here. There what you will measure is only the LOOP itself (not including SELECT's or APPEND's as you did) and of course not with a table with only one CHAR1 field as you had, which is also nonsense.

In my system that shows over 80% improvement. Have you tried in your system that example? What were the results? Were you enlightened?

Best regards,

Rui Dantas

0 Kudos

Hello Rui,

I'm not arguing that LOOP ASSIGNING has better performance over LOOP INTO. Under normal ABAP runtime scenario 80% performance increase is far-fetched.

Of course i had referred to the example you had provided before posting (SE30 -> Tips & Tricks). As a matter of fact i was interested in some real life scenarios where you get such exorbitant performance rise.

BR,

Suhas

0 Kudos

Well, I suppose there is no point in discussing since it seems we all agree.

Anyway, you didn't believe the 80% and you asked for the code snippets, so I gave you the code snippents. You wanted proof and you had it, so I don't know what else to do.

If you want to compare LOOP INTO vs LOOP ASSIGNING then to be fair you have to compare just that (and with real life tables, not one CHAR1 field). If you do that, you will easily see "exorbitant performance rise" for that part of the code. Of course, if something is just 5% of the total time in a program then you cannot expect to improve those 5% and get an overall improvement of 80%.

So in summary:

Will you be able to improve a program by 80% by changing to field symbols? No.

Will the loop itself be up to 80% faster? Yes.

By the way, we digressed from the original question, which mentioned a LOOP... WHERE. For that, as mentioned before, the important part is the WHERE (finding the records), so of course field symbols can't help on that

Regards,

Rui Dantas

former_member215781
Active Participant
0 Kudos

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?

0 Kudos

>

> 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

0 Kudos

@ Rui Pedro - Can you please elaborate more on hashed tables?

0 Kudos

Sim - there is a lot of information about hashed tables in the help files and on the internet - please search.

If you have a specific question about hashed tables, please close this thread and start a new one (One topic per thread).

Rob

former_member194613
Active Contributor
0 Kudos

The ASSIGNING <fs> is an effect of transporting the line into the workarea. The larger the work area the larger the effect.

The ASSIGNING has an initial overhead therefore it is recommended for READs only if the workarea is larger than 1kB.

For LOOPs the inital costs appear only once, i.e if the table has many line than the overhead becomes smaller, so ASSIGINING can

always be used with LOOPs.

=> You can gain some percentage improvements!

Your problem however with the LOOP WHERE is mainly related to the search speed, you need to use a SORTED table where the key corresponds to the fields in the WHERE condition. Or you must optimize the LOOP WHERE manually, SORT, READ ... BINARY SEARCH, LOOP FROM INDEX, EXIT see,

/people/siegfried.boes/blog/2007/09/12/runtimes-of-reads-and-loops-on-internal-tables

section 4

=> You can gain a factor by this improvement, the factor is the number of records in the internal table!

Siegfried

former_member194613
Active Contributor
0 Kudos

Asigning depends on gain the workarea size not in number of but in byte !

WHERE depends on gain in search in a table of n lines, linear n versus logn!

Both effects are independent!

Clear?

I can construct example cases with every possible % gain!

Former Member
0 Kudos

Hi,

In addition to the various responses posted,
it would be important to read the SAP suggestions on Field-Symbol overheads.

http://help.sap.com/saphelp_nw70/helpdata/en/fc/eb3605358411d1829f0000e829fbfe/content.htm

If you are going to Modify the internal table that you are looping on then Field-Symbol is a good idea, if you are only going to Read or Append to another internal table it is better to stick with Work Areas.

Field Symbols may be faster that Work Areas only if the itab has about 10 rows.

Regards

Debashri