ABAP Objects is often accused for being complicated and having slow performance. This blog contains a design and performance benchmark of select, form, static method, and instance method.
In a previous blog – ABAP Objects: Rumble in the Jungle – Internal Table against Collection – I compared collections with internal tables. Some of the comments to the blog indicated that collections complicate things compared with simply using internal tables. The outcome of the blog was that internal tables should be used when programming ABAP. Does this mean that we should not use object-oriented ABAP for anything? Of course not. It is merely one area where you are better off sticking with traditional ABAP using kernel level functionality.
In this blog, I will focus on the encapsulation of select statements in methods. To many this is a no-brainer. Of course you should wrap select statements in methods. However, I have often experienced colleagues presenting arguments about KISS and performance in order to avoid encapsulation of select statements. These developers prefer copying select statements from one place to another, rather than creating a method containing the select statement which can be reused. In order to not make it a question of believing in ABAP Objects or not, I will present some facts regarding design and performance of these coding options.
In the following table TADIR is used for retrieving data. It could have been any table and is only an example. The WHERE condition reads all objects starting with a D. The reason for this is simply that the result in my system is approximately 1 million rows.
Consumer and Producer
From a code design perspective there is basically no overhead in creating classes. Although the pure select statement contains slightly less code, keep in mind that this code is replicated every time it is used. For the classes the select statement is written once and for each caller there are only one or two lines of code. If the select statement is reused the number of lines using methods is less than with the pure select statement. Adding separation of concern to the equation it is clear that encapsulating select statements should be default for any ABAP developer. Choosing between static and instance methods depends on the context the select statement is used in and should be decided on a case-by-case basis.
Below you find the results of the performance benchmark. The results were recorded using transaction SAT. Ten test runs were performed for each type of code. The best result of the test runs is displayed in the table below.
Of course the select statement with no wrapping is the fastet with zero overhead. The form is swift with only 9 microseconds. In my findings the static method used 14 microseconds and the instance method 1 (creation) + 13 (read_tadir) = 14 microseconds to run. The methods runtime is 55% longer compared with the (local) form. But does that matter in this context? The end user will not feel any difference between 9 and 14 microseconds. This is therefore only relevant when methods are frequently called. Otherwise it has insignificant impact on the overall performance.
Looking at the total running time, does this mean that instance methods are the fastest? No, that is a too hasty conclusion. Considering my nonacademic way of testing, the error tolerance is probably 5-20%. Deducting the error tolerance from the performance difference leads to equal results for all coding options. It is notable that using methods consumes <0.0.1% of the overall processing time. I repeated the test by only reading 300 entries from the table. The result is the same, using methods consumes <0.01% of the overall processing time. In other words, wrapping select statement is not a performance bottleneck. In fact, I do believe that encapsulating select statements will lead to better performance. Why? Because you can benefit from the separation of concerns. Your local SQL expert can spend time to optimize the select statements. Optimized select statement are in most cases much faster than select statements written by developers on the fly.