Skip to Content

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.

Design

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.

Select

Consumer and Producer

/wp-content/uploads/2012/01/pb1_126162.gif

Form

Consumer

/wp-content/uploads/2012/01/pb2_126163.gif

Producer

/wp-content/uploads/2012/01/pb3_126164.gif

Static method

Consumer

/wp-content/uploads/2012/01/pb4_126167.gif

Producer

/wp-content/uploads/2012/01/pb5_126168.gif

Instance method

Consumer

/wp-content/uploads/2012/01/pb6_126169.gif

Producer

/wp-content/uploads/2012/01/pb7_126170.gif

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.

Performance

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.

/wp-content/uploads/2012/01/pb8_126171.gif

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.

To report this post you need to login first.

14 Comments

You must be Logged on to comment or reply to a post.

  1. Naimesh Patel
    Hello Elvrez,

    When we select the data, based on the system settings it would fill up the DB Cache. Does your performance measurement influenced by this fact?

    You Wrote:
    In fact, I do believe that encapsulating select statements will lead to better performance. Why? Because you can benefits from the separation of concerns.

    Separation of concern is for better maintenance and re-usability. I don’t think it would improve the performance. Agree that it would allow you to reuse the code and decrease the TCO.

    If you are working with lot of data which should be used across different objects but cost of re-instantiating the object is too high, you should consider using Singleton or Flyweight Design pattern.

    Regards,
    Naimesh Patel

    (0) 
    1. Former Member Post author
      Hi Naimesh,

      I did consider the DB cache and it does impact the performance. However, it impacts all measurements in the same way. Keep in mind that I am focusing on the relative performance here. Furthermore, the most important finding is that the OO overhead is <0.01%, which is not related to DB cache.

      I understand why you disagree on the performance impact of encapsulation. From a technology perspective you are right. But from a real life perspective I think that performance issues are often associated with human mistakes. These can be reduced with separation of concern. (I agree on maintenance and reuse, however, that is not in scooe for this blog post).

      Thanks.

      /Björn-Henrik

      (0) 
    2. Former Member Post author
      Hi Naimesh,

      the db cache does impact the performance. However, I believe it impacts all test measurements in the same way. The focus is on the relative performance of the different coding options and therefore it is of minor importance here. The most significant finding of this blog is that the OO overhead is <0,01% of the total processing time.

      I understand your argument about the separation of concern and agree with you from a technology perspective. From a real life perspective I think that separation of concern can improve performance. Most performance issues with select statements are based on human mistakes. Having experts to write the select statements should help diminish this source of error. You are right about the maintenance and reuse, but that is out of scope for this blog.

      I will check out the Singleton and Flyweight design patterns.

      Thanks.

      /Björn-Henrik

      (0) 
      1. Phillip Manning
        Wouldn’t the different types of parameters also have an effect on runtime?
        I wonder what the difference between and EXPORTING parameter versus a RETURNING parameter would be? Or passing in the table as a data reference to the method and selecting straight into the dereferenced table….

        Phil

        (0) 
        1. Former Member Post author
          Hi Phil,

          good point, I executed some tests now. Here are the results:

          Returning: 14 microsec
          Exporting value: 20 microsec
          Exporting referece: 14 microsec

          /Björn-Henrik

          (0) 
  2. Graham Robinson
    Hi Elvez,

    I like the idea of performance testing different ABAP design patterns/constructs and encourage you to keep up this blog series.

    However I am not convinced this example of testing the same Open SQL statements inside different ABAP constructs is very useful.

    I would like to see you do some performance comparisons of some of the traditional ABAP techniques with the more contemporary ones?

    For example what about testing Persistent Objects versus traditional Open SQL? And how about testing a Business Object defined in the BOR against the same one defined using the BOL?

    Keep up the good work
    Graham Robbo

    (0) 
    1. Ethan Jewett
      Graham,

      Agreed, a more useful benchmark would be something like method invocation vs. calling a function module vs. calling a form.

      In my very basic tests, from fastest to slowest it was:

      1. PERFORM for a FORM defined in the local program. (fastest)

      2. Static method invocation (ABAP OO)

      3. Instance method invocation (ABAP OO)

      4. Function module call

      5. PERFORM for a FORM defined in another program. (slowest)

      Static method invocation was very close (within 10%) of the fastest option, so I really see no performance penalty to using ABAP Objects, especially not compared to other options (4 and 5 above) that provide more similar levels of encapsulation and re-usability. In fact, compared to similar encapsulation options, ABAP OO is far more efficient.

      Cheers,
      Ethan

      (0) 
      1. Former Member Post author
        Hi Ethan,

        I believe that the blog is indirectly covering 1+2+3 but not 4 (this is something I do not see anymore at customer sites and that is reason why I did not add it). 5 is a valuable contribution which I could have added.

        What I have experienced mostly is the case where the select statements are not wrapped at all and that is the reason for composing the blog as it is.

        Thanks.

        /Björn-Henrik

        (0) 
        1. Ethan Jewett
          Hi Brörn-Henrik,

          The problem is that the blog doesn’t really show the difference between the options at all. Because almost all the runtime is taken up by the select statement, it is impossible to see the comparative efficiency of the different types of method invocation. I think you are just seeing random variation in the amount of time it takes to run the SELECT statement.

          You have shown that method invocation time is miniscule compared to the time it takes to execute a SELECT statement. This is a valuable piece of information. I think what would be more helpful in comparing different approaches to encapsulating code is something that focuses more on method invocation efficiency, like the following:

          DATA hmmm TYPE i.

          DO 1000000 TIMES.
            PERFORM humbug CHANGING hmmm.
          ENDDO.

          FORM humbug CHANGING i.
            i = i + 1.
          ENDFORM.

          If you run the same code for static methods, instance methods, non-local forms, and function modules, then you will start to see some significant differences. The key is to make the thing you are trying to test (method invocation) take a significant percentage of total run-time. To do this you need to make the code that the method runs very very simple and fast.

          Cheers,
          Ethan

          (0) 
          1. Former Member Post author
            Hi Ethan,

            great discussion, this is something I really appreciate. You are right about the blog, I should add some figures about the running time of the different types of coding.

            There are some other perspectives to your example, namely the total running time. Lets say it takes 10 microseconds to execute i = i +1 in a form and 100 microseconds from a method. Does this mean that the running times is 10 times longer for methods? No, because it is in fact the above mentioned select statement that is wrapped and nothing else. Furthermore, the end user will feel no difference between 10 or 100 micro seconds and that is what counts. For the end user it is a difference between 4000010 and 4000100 microseconds. Although OO takes 10 times longer (remember that 10 is just a thought example) it does not matter to the end user when it comes to wrapping most select statements.

            Your point is however very relevant if you call a method frequently.

            /Björn-Henrik

            (0) 
            1. Former Member Post author
              … the sentence “For the end user it is a difference between 4000010 and 4000100 microseconds.” should have been “For the end user it is NO difference between 4000010 and 4000100 microseconds.”
              (0) 
    2. Former Member Post author
      Hi Graham,

      when I stop seeing these constructs/arguments at SAP customer sites is the time I stop blogging about them ๐Ÿ™‚

      The perspective of my blogs is taken from experience where the vast majority of coding is done in various types of enhancements. It is not some theory that I come up with. Very often I hear ABAP developers talk about performance tests, but I do not see a lot of documented cases. After 7 years of consulting, I can count perfomance tests (done as part of their regular development) documented by developers on one hand. The performance tests presented here are not scientific and can be performed by anybody. They are more an indication than a proof.

      Thank you for the comment and I will keep it in mind.

      /Björn-Henrik

      (0) 
  3. Paul Hardy
    Greetings!
    You metnioned the whole point of this blog was to disprove the people who say that OO is slower than “normal” programming. Well obviously it isn’t, we have to look at the differnce between what people say and what they mean. When someone says “I don’t like this new thing because of xxxx: what they usually mean is “I don;t like this new thing because it is new”. In such cases arguing is pointless whatever agruments you present will just bounce off. You are just adding fuel to their fire – they say – I must have a point otherwise people would not argue against it. It has been said that “people don’t mind chnage, they do not like being changed”. As an example in my company when we put SAP in people in the Quarry say “I worked with that old system for 30 years, it works perfectly, I am too old to learn new technology, why are they doing this to me?”. They do not voice this complaint to me, they put in on Facebook via their IPAD. So, it really isn’t new technlogy they dislke, whatever they say, it is new technology being forced down their throat. As soon as anyone can see that something brings a concrete benefit to them personally they jump all over it. OO evanlegists say that “old” programmers are stuck in the mud, but often the SAP books / trainung / websites do not dwell on the benefits but just say “DO THIS IT IS BETTER” and if someone asks “why?” the answer comes back “BECAUSE IT IS BETTER”. No-one accepts that argument. If an “old” progarmmer really wants to know I would recommend Igor Barabrics book “Design Patterns in OO Objects” for clear cut simple examples of why OO is useful (better is a too emotive term), and even more learning a little bit about Java / Eclipse, which would make the “recent” changes in ABAP (since 2000) a bit more understandbale.
    (0) 
    1. Former Member Post author
      Hi Paul,

      great comment. I do agree with you. However, I would like to clarify my perspective a little more. For me, it is not about OO or not OO. My endeavour is to find out where – in the ABAP code – to OO and where not to OO. It started with my blog about the ABAP Trilemma, where I state that sometimes you have to comprise on design in order to enhance performance and/or make a solution more secure. In my follow-up blog, I had a look at collections and found that this is a typical area where it is better to stick to the traditional ABAP. Here I focus on wrapping select statements – a tiny fraction of a developers work – and find that this is an area where it does make sense to encapsulate database access. This blog is for developers that have already decided to program OO, but are unsure where to apply it. ABAP is special because it is still a hybrid language. For many years I have wrapped select statements due to a nicer design, but I actually never performance tested it. With this blog I know that doing so was the right decision.

      Let me continue the dialog you have started in your comment:

      OO developer: “BECAUSE IT IS BETTER”

      Traditional developer: “OK, YOU SAY THAT IT IS BETTER DESIGN, BUT IT IS BAD FOR PERFORMANCE AND THAT IS OUR TOP PRIORITY”

      OO developer: “NO IT IS NOT BAD FOR PERFORMANCE”

      Traditional developer: “YES”

      … this is when the OO developer needs to move away from a general discussion to being more specific and that is what I hope my blogs help the OO developer with.

      /Björn-Henrik

      (0) 

Leave a Reply