Skip to Content

ABAP Objects: Rumble in the Jungle – Internal Table against Collection

Let’s get ready to ABAP Rumble! 

This blog covers a great fight between the ABAP champion Internal Table and challenger Collection. The purpose of the blog is a response to many of the excellent comments received in my previous blog ABAP Trilemma  (ABAP Trilemma), such as for example the blog Object Orientation and Performance – Mission Impossible?

Fighter Champion – Internal Table 

Internal Table is one of the most used concepts in ABAP programming and needs no further introduction here. More information can be found on

In this blog, I will use a standard internal table of type MAKT, material descriptions.

Fighter Challenger – Collection 

Collection is a very well-known concept in object-oriented languages. It is a dynamic array. More information on Collection can be found here

At first I wanted to use class CL_OBJECT_COLLECTION for the challenge, but that would be unfair as there is no easy way to retrieve a single object in a collection. Therefore, the challenger is a special type of collection called a map.  Unlike the CL_OBJECT_COLLECTION, it is possible to get a single entry by key in the map. This seems more fair compared with the read functionality of the internal table. The map is represented by standard class CL_OBJECT_MAP.

The objects of the collection is a custom class representation of material description. Please note that simply transferring a standard structure into a class is not something that I usually recommend. The purpose here is to be able to compare the Collection with the Internal Table. In real-life the class would span several structures and of course contain methods with logic rather than just get and set methods. I call the class ZCL_MAKT:


The class can be downloaded as a nugget here, please go to SAPlink for more information on nuggets.

Round One – Design 

From a design perspective I would prefer using a combination of collection/object instead of internal table/structure. It also follows the official SAP ABAP Guideline DEV-ABAP-2.

Please be aware that I have put no effort into making correct ABAP coding in this blog. The code is optimized so that it is easy to read and understand. Furthermore, I have tried to code in a way that makes the performance results comparable.

Lets have a look at how the coding differs:

Init Design

Prepare data in the Internal Table or Collection.

Internal Table:




Loop Design

Loop or iterate all entries of the Collection or Internal Table.

Internal Table:




Update Design

Update all records of the Collection or Internal Table.

Internal Table:




Read Design

This functionality reads one entry of the Collection or Internal Table.

Internal Table:




For the lazy developer, the code can be downloaded as a nugget here.

If you are an OO purist, the winner of Round One is: Collection. 

Round Two – Performance and Memory Consumption

I am by no means an expert on ABAP performance and memory analysis. I have simply followed Olga Dolinskaja ‘s blogs on performance  (Next Generation ABAP Runtime Analysis (SAT) – How to analyze performance) and memory analysis  (Next Generation ABAP Runtime Analysis (SAT) – How to analyze memory consumption) using transaction SAT. Do not focus on the absolute figures, it is the relation between the Map and Internal Table that counts. Here are the results:


Init Performance and Memory Consumption

The Init part of the performance analysis is the most scary reading of my findings. As you can see the processing time of the Map goes up by a factor 10 everytime the number of records increases by one. That is exponential growth!

Even the processing time of 1000 records is a staggering 13 times longer for the Map than for the Internal Table. For 100000 records it i 167 times longer … uhh … 167 times!

You probably think this has to do with my coding. I believe not. It turns out that it is the underlying PUT method of CL_OBJECT_MAP that is the performance bottleneck.

Although Internal Table has lower memory utilization it don’t think that it makes a significant difference compared with the performance difference.

Loop Performance and Memory Consumption

The Loop performance of the Map is at least linear when it comes to iterating, but much worse than the Internal Table loop. Actually, the processing time is 27 times longer with 1000 records and 52 times longer with 10000.

The memory utilization is the same as for Init.

Update Performance and Memory Consumption

The Update performance of the Map is also linear, but much worse than the Internal Table loop. Actually, the processing time is 15 times longer for 1000 records and 30 times longer with 10000.

Same as for Init and Loop.

Read Performance and Memory Consumption 

The Read performance of the Map is better than the Internal Table However, as you can see the total processing time is low and therefore this advantage will have minor impact on the overall performance. Furthermore, the error tolerance of my unacademic way of testing exceeds the performance difference.

The memory utilization is that same as the previous examples.

The winnder of Round Two is: Internal Table. Depending on your priorities in the ABAP triangle you will either choose Internal Table or Collection. For large data volumes performance is key and therefore the answer is … Internal Table.

You must be Logged on to comment or reply to a post.
  • It’s strange that you are comparing a “kernel level” function against user level function.  I don’t know why you dislike internal tables as it’s basic language feature and trying to make them more complicated with objects violates the KISS priniciple.  Don’t see the point in trying to replace something that works well for the point of a overcomplicated abstraction.

    Take care,


    • Hi Stephen,

      I guess you noticed that internal tables did win the match?

      Anyway, I really like internal tables, but if performance of collections would be as good as internal tables, then I would use collections.


      • As others have said, and as I’m guessing you knew before hand, it is obvious internal tables will win as they are already highly optimized for regular ABAP reporting.

        What your results do highlight is that there is a problem with the (SAP standard)  class code that is making it exponentially slower. And, as others have written in the comments, internally the class code is using an internal table, perhaps this internal table is not being indexed correctly.

      • I just find it very strange that we are trying to compare “user level code” with a kernel level function in a intepreted language.  Let’s forget about object orientation, but the deck is always stacked against user level code in high level language such as ABAP unless the low level implementation stinks.

        If ABAP was a lower level langauge like C or C++ or nature, perhaps we might be able to do it better than delivered.  I think even in a language like java it’s going to be hard to perfom better than statement that is part of the language itself.

        Personally instead of recreating the wheel of basic language features, I would love to see how we could make ABAP Objects implement true polymorphism.  I just don’t see how a java developer would be uncomfortable with a internal table, unless they really like to manage arrays themselves ;).

        Take care,


  • Hi Elvez,

    Thanks for your time putting this together.
    I think this is quite a strange comparison, because the class CL_OBJECT_MAP is a wrapper for an internal table.

    So you are actually comparing two internal tables and the difference in performance is the ABAP code from the class CL_OBJECT_MAP.

    Probably the reason why the PUT method doesn’t have the best performance is because it first determines if the key already exists in the internal table, but the definition of the internal table doesn’t have an index so it does a full table scan.

    Regards, Robin Vleeschhouwer

    • Hi Robin,

      correct, it is a wrapper, but what other options do we have for collections in ABAP?

      If it is just a wrapper, why does the performance differ so significantly?

      Just some thoughts …


  • Hello Elvez,

    I guess you are not comparing Apple to Apple. Using internal table, you have flat structure where as the MAP is collection of objects in an internal table.

    The drastic time difference in performance of INIT method is because of this reason: One is direct table append vs another is create object, read table for key and append.

    IMHO, its not apple-vs-apple comparison.

    Naimesh Patel

    • Hi Naimesh,

      thanks for your comment. I am not trying to compare “Apple to Apple”. The purpose of the blog is to take one tiny example where I had to compromise between design and performance.

      You are not right about the time difference, creating the object is not the performance bottleneck. The PUT method is utilizing +99% of the time. The creation of the object is not a significant performance problem.


      • Hello,

        I am little confused – are you same as Elvez?

        Yes, PUT method takes most of the time about 96%. From that 95% is spent on the READ statement. As it tries to check for key without binary search.

        Naimesh Patel

      • The performance issue for the MAP approach may be partly due to the fact that you’re using a standard table:

            ty_map type standard table of ty_map_element .

        If you change this to using a sorted or hashed table, you will experience a drastic reduction in resource consumption:

            ty_map type HASHED TABLE OF ty_map_element WITH UNIQUE key key.

        I did this by copying the class CL_OBJECT_MAP and changing the type as per the above. This also requires slight changes to the PUT method…

        Roughly, the “new” version runs at around 10% of the original. I haven’t done any detailed analysis yet, but the main point seems to be that the standard methods of CL_OBJECT_MAP are not optimal for large collections.

        Which basically only proves that when working with internal tables, you have to choose the right type for the work at hand :-)))


  • How did you decide that round one winner is collections. The number of lines of code is less for internal table and easier to understand. so I guess it should be the winner.
    • Hi Raghavendra,

      the text regarding the winner of round one is now updated. I believe, that an OO purist would regard collections a better design.

      Focusing on the number of lines of code, is misleading I believe. Perhaps you remember ABAP macros? They had very few lines of code, is that good design? I know that some people refer KISS to few lines of code. That is ok, as long as there is no blackbox programming involved and it is easy to read and understand.

      Regarding, “easier to understand”, I think this is a question of your background. A C# or Java developer would probably find the collection easier to understand.



  • First of all: thanks for this thorough analysis and contribution to the ongoing debate of OO vs classical ABAP. What a great way to start the brand new year – I frankly thought the first week in office would be rather boring. Not so!

    I would argue that your example is a wee bit contrived. When processing large sets of data (here: materials) I would also resort to using internal tables. My class would simply hold an internal table of MAKT entries, instead of an array of object references. The overall design of the application would still adhere to OO principles, while maintaining focus on design.

    I’m aware that this is something akin to heresy for OO purists, but I believe the overall design of the application would not suffer as a consequence. What I’m principally against is the resort to writing procedural programs as opposed to a decent modelling of the application, just based on the perception that OO is “slower” or lacks performance. There are so many benefits of OO that are sadly overlooked, some times due to a lack of pragmatism.

    Yes, ideally the “collection” object should contain nothing but pointers to each and every instance of MAKT that you’d want to manipulate, but with the current architectural constraints we have to live with (meaning access to the persistent layer) this is simply not feasible. This may change with the introduction of HANA and/or adoption of persistent objects, and it would be interesting to see a re-run of the resource analysis in these scenarios.

    To sum up: to me, it’s the overall design of the application that matters, not the forcing of die-hard OO principles in the extreme. Whether you use an internal table or a set of object references as your attribute, is of less importance. Clearly, when working with large sets of data, the internal table representation is favourable – as we all probably knew already – and I don’t see this as betraying the OO guidelines, as some others might 🙂


    • Hi Trond,

      your comment and summary is exactly the point of this blog. Using internal tables does not rule out OO and vice versa.

      In a next blog, I will focus on the co-existence of objects and internal tables.



  • Internal tables are way ahead when it comes to ease of use, take case of simple sorting by multiple keys, it is very easy on internal table with a SORT command, but it is definitely more complicated using collections. I would say replacing internal tables with collections only invite more complication in the code which could otherwise be done in more simpler way.
    • well things  look different when it comes to unit tests i guess there a collection would rule because you easily can mock it..

      nevertheless i think it is not about OO vs. classical ABAP, it is about Design, Performance, Changeability and choosing the right tools for the right job..

      Anyway, thank for the Blog