Currently Being Moderated

Object Orientation and Performance - Mission Impossible?

Why is OO perceived as incompatible with high performance? I asked myself the question after reading one of the comments to the blog ABAP Trilemma, where the author discusses the weighted relevance of Security, Performance and Design. The comment related to the well-known "truth" (some would call it Conventional Wisdom) that Object Orientation and Performance does not go well together.

I posted a brief reply to this comment, but realized this is too important a subject to be left alone. Hence this (hopefully) provoking rant.

The two tongues of ABAP

The ABAP world is unique in the sense that it spans the cleft between the two main design paradigms in computer programming; Procedural and Object Oriented. To my knowledge, no other language has such a schizophrenic group of followers as ABAP. On one end, there are the "Object Evangelists", a mix of converted oldtimers who have seen the light and the younger generation of developers who never bothered with any of the stone-age languages in the first place. On the other side, we have the "Procedural Protestants", firmly rooted in the lore of Cobol, PL/1 and other legacies of the largely IBM mainframe way of doing things - the origins of SAP.

The comment focused on the well-known "fact" that Object Orientation does not mix well with high performance. Good design (and strangely everyone - regardless of camp affiliation - seem to agree that this means Object oriented programming) implicitly means we'll have to sacrifice something on the performance side. If it looks nice, it won't run well.

Should we believe this? Honestly, I don't think so. Not anymore. Let's look at what the above "truth" implies. I will do this by postulating a few theses of my own.

1. Applications dealing with high data volumes can be made less complex with OO.

Most of the applications dealing with high data volumes tend to be fairly straight-forward, conceptually. They read data, process, then provide some form of output or data update. This should actually provide a good reason for dealing with it in an OO-centric way. The data access itself is usually down to relatively simple select statements (I'll deal with that later). What complicates matters is the actual manipulation of the data, and it's my humble opinion that this is far better handled by architecting a proper OO development. Defining and using business objects and their methods will simplify the application, as opposed to writing a (perceived) streamlined classical ABAP, complete with subroutines and call to function modules. The OO-based application will be easier to read, maintain, and should not bog down your system perceivably. Even if it does, there are other techniques you can use, such as Shared Memory Objects, parallel processing (qRFC's) and so on. None of these techniques are tied to classical, procedural ABAP.

2. Performance issues are largely related to (persistent) data access.

Most of the performance-related issues with large data volumes relate to the DB access itself. This is largely independent of the application design. Considerations such as intelligent table access via proper indexes, reading a limited set of fields, proper use of indexed internal tables and so on can easily be done also within an OO context. If the report or application is going to be run consecutively with varying select criteria or processing parameters, one should consider building a shared memory object to hold the desired data, as opposed to repeatedly reading large data volumes from data base tables. Again, splitting the processing using tRFC's or the newer qRFC technique should be investigated. In any way, the DB access issues are not related to how the application itself is designed.

3. What about the other aspects of "performance"?

There are different flavours of "performance". What about reuse? Ease of maintenance? Total cost of ownership for procedural vs OO? I'd much rather maintain and enhance an (well-written and properly structured) OO application than a 5000-line procedural monster. Anytime. Also, I've never seen an ABAP application that has not been modified at a later point in time. In more than 95% of the cases, the modifications have been done by another developer than the creator of the original application. Usually from a different service provider, as well. I believe this speaks for itself.

4. The "OO is not performance-friendly" statement is used as an excuse to avoid having to learn OO.

Lastly, and maybe most importantly, I believe the "OO is not performance-friendly" mantra is - to a large extent - being put forth by those developers/managers/devco's who are not too comfortable with the OO world themselves, in order to avoid having to deal with it. It's convenient to chuck the whole OO discussion down the drains by using a cheap argument. Also, I believe that most of the ABAP'ers dealing with performance-related developments are still very firmly rooted in the procedural world. No offense intended.


Sure, there are cases where a short, 50-lines procedural ABAP does the trick, and can be written in 5 minutes - as opposed to doing an OO design approach. But these are exceptions. Normally, you don't get assignments like this. Your standard development project spans weeks, if not months, and involve whole teams of programmers, not just you.

This last statement also shows the OO-induced shift towards a more community-centric way of working (think Scrum, Agile, XP). Speaking in OO is, to some extent, a social experience. Your team is developing a community of entities (objects) that work together to resolve a common goal. Creating a behemoth of a procedural beast is more often than not a fairly lonely task, undertaken in splendid isolation in a cubicle or office at the end of the corridor. As we did in the past.