Just 3 Changes to Improve the SAP ABAP Performance by 95 Percent

sap abap performance tuning

For one of our custom program, if the Business Team executed it wide open, it took almost 10,000 seconds. So they were advised to always run the report with some input values in the selection screen. Even if they want to execute for all the users (blank open) in the selection screen, they were asked not to leave it blank. Instead, they were asked to put users input field in ranges and then run multiple jobs.

For example:

Users 00000001 – 00005000 – Job 1
Users 00005001 – 00010000 – Job 2
Users 00010001 – 00015000 – Job 3
Users 00015001 – 00020000 – Job 4 – and so on.

sap abap selection screen

But, one of the Business Team members was not happy. He did not like the idea to run multiple jobs and then assemble the results. He wanted to run the report wide open and have just one spool with the output. He made his voice loud, made it heard and convinced the management to tune this program. As a result, this dreaded program came to our plate to analyze if we can make some improvement.

performance tuning abap

Our first move was to run the job wide open and check how long it took. It took 9991 seconds precisely. We ran it wide open multiple times to check if any buffer would do any trick. But the job took a similar time to finish.

Then we looked at the program and did a couple of changes, which we believed had the maximum impact. In short, we followed “The Pareto Principle”, also known as the “80/20 Rule”. I am sure most of you have heard about this 80-20 Rule. The law states that, for many events, roughly 80% of the effects come from 20% of the causes.

In our context, 80 percent of Performance Issues have 20 percent causes. Or, 80 percent of Performance can be improved by fixing the top 20 percent bad programming. 😛

We did just 3 changes and the impact was huge. Check the below job run Duration. With just 3 changes, the run time fell from 9991 seconds to 496 seconds.

Yes, an improvement of over 95%. Isn’t it mind blowing? Although 496 seconds is not an ideal time to complete a report. But to get that reduction in time with just some minor code change was really worth mentioning.

The Pareto Principle

Some folks may ask for proof. How can we believe if both the jobs ran for same input and gave the same output.?Yes, it did. And here is the proof.

This is the Input. We want for all Users. And all our users start with 0.

The job which ran for 9991 seconds gave 632 Pages output.

The job which ran for little less than 500 seconds also gave 632 Pages output

Now, you would be curious to know, what was the magical change which we did? Nothing special though. 😀 You might be disappointed after learning the change.

But still, we wanted to publish this article because sometimes we do NOT need to move the mountain to attain something. Sometimes, the solution is simple and within our reach. We always need NOT have to have In-Memory Database to see the performance improvement.

Sometimes, tweaking our code in the traditional database might do the trick. This is just an example to demonstrate, how bad we can program. If all ABAPers take care of minor things like shown below, the client’s SAP System would be much faster, smoother and more importantly optimized even without HANA.

This does not mean we can avoid HANA. 😀

Also Read: SAP Screen Personas – Performance Woes

Changes done:

  1. Change Standard Table Types to Hashed and Sorted Internal Tables wherever possible.

Check the commented DATA in green. All Standard Internal Tables are replace by Hashed and Sorted Internal table.

Hashed internal table

  1. Alternative for ‘For All Entries’

HRP1001 has more than 4.5 million entries in our system and the below FOR ALL ENTRIES (FAE) select took forever.

Before Code Change

After Code Change

After analyzing the runtime data, we found that the FAE driver table IT_PA0001 had only 7000 unique entries, but the FOR ALL ENTRIES took almost perennial to complete because the selected database had over 4.5 million records. So we decided to put these 7000 odd entries to Range Table and use it in the WHERE clause.

  1. Actually, there is no Third point. This is the after effect of First point. The LOOPs and READs of HASHED and SORTED tables are by default efficient than STANDARD INTERNAL Tables.

That’s all. Just the above two changes improved the performance dramatically (by 95%). Hopefully, this article would motivate you to use the SORTed and HASHed table more often than STANDARD.

Also Check: DELETING rows of the internal table within the LOOP. Is it a Taboo? A big NO NO?

Question: Before we close today, let me ask you, Do you know how many types of internal tables we have in SAP?

Answer: Did you say 3? Standard/Sorted/Hashed? Hopefully not. 😛

Broadly speaking, there are only 2 types of Internal tables. INDEX Table and HASHED Tables.

Then what about STANDARD and SORTED? They both fall under INDEX Table umbrella. 😀

This image would clarify, Types of Internal Tables in SAP.

Types of Internal Tables in SAP

But why are we covering Internal Tables here?

Isn’t Internal Tables theory for beginners in ABAP?

True, internal tables are the basic concept which is told to beginners. But at times, we need to remind our experienced folks as well that the second prominent culprit for most of the Performance Issues after Database Access is operations with Internal tables. Wrong or Incorrect Database Fetch no doubt causes issue, but wrong Internal Table at the wrong place also adds insult to the injury. 🙂

So, Internal Tables being the central construct within the application development with ABAP, its importance cannot be undermined.

How to chose the internal table type?

Standard Internal Table (Indexed)

i. If you are sure, your internal table would very few records (less than 100) it may be advisable to forgo an explicit key altogether (which is needed in sorted and hashed tables) then Standard Internal tables can be used. Standard tables are suitable for data which are rarely or not at all searched for specific

ii. If the internal table data are rarely or not at all searched for specific criteria then Standard Internal Table would be suitable for such data.

iii. Thumb Rule – If searches are not needed in the internal table then it is not worth the costs to create and to keep the additional key-structures needed for the other table types (sorted/hashed). Use Standard Internal Table safely.

Sorted Internal Table (Indexed)

i. If you want to LOOP with WHERE clause. If this is done with proper Keys (even partial), the internally built key-structures will be used to find the corresponding entries as quickly as possible.

ii. If the data needs to be searched with Keys. If the READs would be done with Partial Keys, then SORTed is the best table type not Hashed table.

iii. Thumb Rule – If the unambiguity of the Keys cannot be guaranteed i.e. only Partial Keys are known, then Sorted Internal Tables should be used.

Hashed Internal Table (Hashed)

i. If you have the COMPLETE Key (NOT Partial), Hashed Internal Table is your best choice.

ii. If unambiguity of the Keys CAN be guaranteed i.e. Full Keys are available for the searches, Hashed in the Best.

iii. Thumb Rule – If the search term always uses the complete key (all the fields of the key are checked against the corresponding value) Hashed table type is usually the best.

Summary of the above explanation of Time Costs for Key Access.


Summary of the above explanation for When to Use Which Table Type?

When to Use Which Table Type?

As our SAP Mentors always say, if we could optimize our custom codes in the traditional database, we could achieve tremendous improvement in performance even before we move to HANA.

Create your first Program in SAP HANA ABAP.

What do you guys say? Do you have any such Optimization Story to share?

Please share your performance woe stories and leave your quick comment below.


  1. Hi Raju,
    it’s a great one to learn something like this.
    For overcoming the DUMP(max number of lines is restricted in 9999) in range. Why can’t we do as below?

    lwa_objid-sign = ‘I’.
    lwa_objid-option = ‘BT’.
    lwa_objid-low = (First record of internal table).
    lwa_objid-high = (last record of internal table).
    append lwa_objid.

    then pass this range to our select statement.


  2. Nice article Raju. This will help beginners also to understand the importance of using the right type of internal table to enhance the program performance.

  3. I have two comments:
    1. If your range can have 10.000 or more entries, you will have a DUMP becausa max number of lines is restricted in 9999, is possible to increase it? I’m looking for it.
    2. I applied the recomendations for internal table you suggested, and now i have a program that runs 80% faster. Thank you so much

    • Dear Nestor – Thank you for your feedback.

      1. True. There is limitation of 9999 in range table. We should find a way to check the entries in range table. And device a way to split the range table once it crosses 9999 ( may be when it reaches 9990).

      2. Wow!!! 80% improved with just changing Internal Table Types. That is incredible. This shows, everyone of us have the scope to improve and optimize our programming even without HANA Database. 🙂

      If you could share your before and after code along with before and after execution time, we can update it in this article with your Input. 🙂

      Our email id is mail@sapyard.com

      Thanking you.
      Team SAPYard.

    • about point 1, usually if your range is so big is because you maybe is used only with “LOW” field (and probably with “EQ” operator).. If this is the case using a one field internal table in “FOR ALL ENTRIES” select statement is surely much better (following also the way explained in the article above, no duplicates)..

  4. Hi,

    Isn’t FAE better than ranges?
    Range has some limitation if it exceeds it goes for dump, besides that we have to loop the internal table adding process time.


  5. Hi

    Thank you for the insights. Just wondering, whats the table type for it_hrp1001?
    Wrt hashed tables, read somewhere were it said you cannot use them if the number of entries exceeds 2 million. How true is it.

    Kind regards

    • Dear The Bishop – Thank you very much for your questions.

      1. it_hrp1001 TYPE SORTED TABLE OF hrp1001 WITH NON-UNIQUE KEY objid.
      2. We are not sure about the 2 million restriction on Hashed tables. We will do some research and ask the experts and get back to you.

      Please keep visiting.

      Team SAPYard.

Leave a Reply to sapyard Cancel reply

Please enter your comment!
Please enter your name here