Friday, January 21, 2011

ABAP performance tuning lessons learned

I Have learned a few lesions in ABAP performance tuning that may seem obvious but good to note just the same.
1.       Always keep a working copy of the original program to compare your results against when re-coding.
a.       This became very handy as I put an extra join in the select statement so that I wouldn’t have to get the information in it’s own select to see if that would increase the speed of execution, but the report came out different than the original. I then remembered that in inner joins, all data that is in all tables for the selection criteria is returned, if anything is not in one of the tables, you get nothing back for that entry at all. I should have used an outer join, but that is beside the point now.
2.       When selecting from the database tables, try and use as many of the primary table keys as you have available. I have been told that the data base tables are usually hashed tables the SQL statement using the most keys can retrieve the information the best as compared to using 1 key or a non-key.
3.       Used hashed tables whenever you can.
a.       I was selecting information into standard tables and then reading the table in a nested loop to fill in the information into the ITAB as I was preparing the output of the report this was causing the tables that I was reading to be looped through at each read and that was time consuming. I had 4 tables with thousands of records in each table. I changed those into hashed tables using the same unique keys as used in the database tables so that when I selected the information for all entries in my internal table using the select distinct * from table into ITAB where key = table-key, I got what I needed and then used the “read table with table key = table-key” statement which with a hashed table has an almost instant return for the item.

When all was said and done, I managed to take a program that was running 13 seconds in the DEV system and trim it down to a 2 second runtime. In the QA system, it ran just as fast. The report returned in just over 2 seconds. The defect stated that it was taking up to an hour to run the report due to the volume of data in the report. This makes a great reason to use hashed tables whenever possible.

Post a Comment