topic Re: Performance with internal tables in Application Development and Automation Discussions

Performance with internal tables

Former Member — Fri, 08 Jul 2005 16:36:11 GMT

Hi everybody,

I'm having trouble with the performance of a report.

The reports selects data out of many different tables and merges them together in one extraction file. (I would really like it to be executable in dialog task, because I don't want to write the file on the application sever)

I've done what I could using runtime analysis to improve performance of the db accesses. Now 97% of runtime is consumed by abap.

I'm using several internal tables which will have many entries, and at the moment I'm using nested loops to gather the information out of the internal tables into one extraction file. (Reading the internal tables with key is not always possible, I do this whenever possible)

I've tried to use loop... assigning <fs> instead of loop... into, but it doesn't really help too much.

Any other suggestions?

Thank you for your help, regards, Kathrin!

Re: Performance with internal tables

Former Member — Fri, 08 Jul 2005 17:07:59 GMT

Hi,

Some of these might be able to help for improving the performance.

1. Read table with key using binary search.

2. While comparing two internal tables, user Kernal

method. Eg: If I_TAB1[] = I_TAB2[]. Enfif.

3. Instead of appending records within loop/endloop,

use 'Append lines of'.

4. When populate different internal tables, try to create

with key field which will make a big difference while

accessing the data.

5. Sort the internal tables.

6. Use Case/Endcase in place of If/Endif.

7. While making values negative, use 0 - <field>, in

place of <field> * -1.

8. If the field structures are similar in two internal

tables, for appending records use I_TAB2[] = I_TAB1[].

9. After the complete usage of internal tables, release

the resources using FREE/FREFRESH <internal table>.

10. For data extraction, use field by field selection

from database.

11. Try to avoid using 'ALL ENTRIES'. If using and make

sure that the ref.internal table have entries.

12. Try using Inner Join using Foriegn key fields.

13. To get sum or count use Aggregate functions.

14. Try to use Views if need appropriately.

Hope this helps.

Gopakumar

Re: Performance with internal tables

christian_wohlfahrt — Fri, 08 Jul 2005 18:43:26 GMT

Hi,

this is a good list, so

15. If you can define keys for internal tables, define sorted or hashed tables.

15a. Use sorted tables, if you use 'loop at ... where', with your where clause as partial key.

15b. Use hashed tables, if you have full key access.

16. Try to avoid unecessary SORT (on big tables with a lot of sort fields).

Regards,

Christian

Re: Performance with internal tables

juan_suros — Fri, 08 Jul 2005 23:49:50 GMT

I see you have lots of good suggestions already.

One trick that sometimes gets forgotten is that you can fill new internal table records very quickly this way:


APPEND INITIAL LINE TO itab ASSIGNING <line> 
LOOP AT itab2 ASSIGNING <line2>.
  <line>-field = <line2>-field.
ENDLOOP.

Other than this, I'll echo the advice above on defining your internal tables as type SORTED or HASHED. This saves a lot of time.

I can't be more specific without more detail.

Good luck!

Re: Performance with internal tables

Former Member — Sat, 09 Jul 2005 05:48:29 GMT

'Now 97% of runtime is consumed by abap'

Why it cost you so much on ABAP?

Can you tell us what is the most cost part in your application? How many entris your application will handle normally?

In addition, a suggestion: don't delete or modify in a internal LOOP(like following), if possible.

LOOP AT ITAB INTO LC_ENTRY WHERE XXXX.

DELETE(MODIFY) .....

ENDLOOP.

Assume your internal table is very large, modify specially delete very often in loop will cost much, if the populate times is too many, the cumulative cost will be large.

And delete the dynamic table and dynamic generate tech in your application, if they exists. They always cost a lot.

Re: Performance with internal tables

Former Member — Sat, 09 Jul 2005 10:28:19 GMT

Hi Kathrin,

There's one small point that you need to consider. Don't get too carried away by the persentages that you find in the Runtime Analysis. It is only to help you have a rough idea about where the optimization needs to be done.

The three components that you find there, ABAP , Database and R/3 system will togetther make up the 100%. So, even if you try to reduce one of them, the other has to go up, to make the total 100 !! And then you try to see what's gone wrong.....

This is a simple fact, but very often I find ABAP developers not noticing this. They are always trying to bring down everything :-).

Though in your case, 97% in ABAP may be considered to be a bit on the higher side.

Regards,

Anand Mandalika.

Re: Performance with internal tables

VijayasekarK — Sat, 09 Jul 2005 11:30:22 GMT

Hi ,

I would like to add one more point which normally most of us forget. Before using the internal tables in SELECT Statements ( ..FOR ALL ENTRIES) , checking the internal table for records is very essential.

Regards,

K Vijayasekar.

Re: Performance with internal tables

Former Member — Sun, 10 Jul 2005 05:33:23 GMT

How would u compare case/endcase against if/endif ?

Regards,

Nitin

Re: Performance with internal tables

Former Member — Mon, 11 Jul 2005 15:01:36 GMT

That's point# 11 that I mentioned in the earlier list.

11. Try to avoid using 'ALL ENTRIES'. If using and make

sure that the ref.internal table have entries.

Regards

Gopakumar

Re: Performance with internal tables

MariaJooRocha — Tue, 12 Jul 2005 14:37:16 GMT

Hi,

You say "Now 97% of runtime is consumed by abap". I've been working on a report that takes more than 24h running - we applied the knowledge of the Performance Tunning Course and verified that the problem was precisely on the amount of data in internal tables.

We changed the report, to reduce the loops on the giants internal tables and this action optimize the performance.

That's a bit strange, because in all most of our performance optimizations we use the internal tables...(but not so fat)

Regards,

Maria João Rocha