Why do so many developers believe performance, readability, and maintainability cannot coexist?

Question

While responding to this question, I began to wonder why so many developers believe a good design should not account for performance because doing so would affect readability and/or maintainability.

I believe that a good design also takes performance into consideration at the time it is written, and that a good developer with a good design can write an efficient program without adversely affecting readability or maintainability.

While I acknowledge that there are extreme cases, Why do many developers insist an efficient program/design will result in poor readability and/or poor maintainability, and consequently that performance should not be a design consideration?

Answer 1

I think such views are usually reactions to attempts at premature (micro-)optimization, which is still prevalent, and usually does way more harm than good. When one tries to counter such views, it is easy to fall into - or at least look like - the other extreme.

It is nevertheless true that with the enormous development of hardware resources in recent decades, for most of the programs written today, performance ceased to be a major limiting factor. Of course, one should take into account expected and achievable performance during design phase, in order to identify the cases when performance may be(come) a major issue. And then it is indeed important to design for performance from the beginning. However, overall simplicity, readability and maintainability is still more important. As others noted, performance optimized code is more complex, harder to read and maintain, and more bug-prone than the simplest working solution. Thus any effort spent on optimization must be proven - not just believed - to bring real benefits, while degrading the long term maintainability of the program as little as possible. So a good design isolates the complex, performance intensive parts from the rest of the code, which is kept as simple and clean as possible.

Answer 2

There are also some famous pieces of highly optimised code that will bend most peoples brains that support the case that highly optimised code is difficult to read and understand.

Here's the most famous I think. Taken from Quake III Arena and attributed to John Carmak, although I think there's been several iterations of this function and it wasn't originally created by him (isn't Wikipedia great?).

float Q_rsqrt( float number )
{
    long i;
    float x2, y;
    const float threehalfs = 1.5F;

    x2 = number * 0.5F;
    y  = number;
    i  = * ( long * ) &y;                       // evil floating point bit level hacking
    i  = 0x5f3759df - ( i >> 1 );               // what the fuck?
    y  = * ( float * ) &i;
    y  = y * ( threehalfs - ( x2 * y * y ) );   // 1st iteration
    //      y  = y * ( threehalfs - ( x2 * y * y ) );   // 2nd iteration, this can be removed

    return y;
}

Answer 3

You can have both well-readable and good-performing code to some extent if you are using a lot of libraries, especially home-grown ones. These libraries are supposed to be widely used in other projects, therefore have few errors.

Programming at a higher level is key to productivity.

For maintenance, in newer versions of libraries, interfaces (method-signature) should be same, inner implementation should vary.

Personally, I write lots of extension methods. The idea is to compose all of your home-grown libraries with as much static methods as you can.

You can combine the above techniques with method chaining, by returning from your static library method the main object the method has worked on, with inner state of the object changed.

Answer 4

Because experienced programmers have learned that it's true.

We've worked with code that is lean and mean and doesn't have performance issues.

We've worked on a lot of code that, to address performance issues is VERY complex.

One immediate example that comes to mind is that my last project included 8,192 manually sharded SQL tables. This was needed because of performance issues. The setup to select from 1 table is a lot simpler than to select from and maintain 8,192 shards.

Answer 5

One problem is that finite developer time means that whatever you seek to optimise takes away from spending time on the other issues.

There's a rather good experiment done on this referenced in Meyer's Code Complete. Different groups of developers were asked to optimise for speed, memory usage, readability, robustness and so forth. It was found that their projects scored high in whatever they were asked to optimise in, but lower in all the other qualities.

Answer 6

Because the cost of global warming (from those extra CPU cycles scaled by hundreds of millions of PCs plus massive data center facilities) and mediocre battery life (on user's mobile devices), as required to run their poorly optimized code, rarely shows up on most programmer's performance or peer reviews.

It's an economic negative externality, similar to a form of ignored pollution. So the cost/benefit ratio of thinking about performance at all is mentally skewed from reality.

Hardware designers have been working hard adding power save and clock scaling features to the latest CPUs. It's up to programmers to let the hardware take advantage of these capabilities more often, by not chewing up every CPU clock cycle available.

ADDED: Back in ancient times, the cost of the one computer was millions, so optimizing CPU time was very important. Then the cost of developing and maintaining the code became greater than the cost of the computers, so optimization fell way out of favor compared with programmer productivity. Now, however, another cost is becoming greater than the cost of computers, the cost of powering and cooling all those data centers is now becoming greater than the cost of all the processors inside.

Answer 7

Coming at your question from the side of a developer who works on high-performance code, there are several things to consider in design.

• Do not prematurely pessimize. When you have the choice between two designs that are equal in complexity, choose the one that has the best performance characteristics. One of the famous C++ examples is the prevalence of post-increment of counters (or iterators) in loops. This is a totally unnecessary premature pessimization that MAY not cost you anything, but it MIGHT, so don't do it.
• In many cases you have no business to go anywhere near micro-optimization yet. Algorithmic optimizations are a lower-hanging fruit and are nearly always a lot easier to understand than really low-level optimizations.
• If and ONLY if performance is absolutely critical, you get down and dirty. Actually, you isolate the code as much as you can first, and THEN you get down and dirty. And it gets really dirty in there, with caching schemes, lazy evaluation, memory layout optimization for caching, blocks of inline intrinsics or assembly, layer-upon-layer of templates, etc. You test and document like crazy here, you know it's going to hurt if you have to do any maintenance in this code, but you have to because performance is absolutely critical. Edit: By the way, I'm not saying this code cannot be beautiful, and it should be made as beautiful as it can be, but it's still going to be very complex and often convoluted compared to less optimized code.

Get it right, get it beautiful, get it fast. In that order.

Answer 8

I think most programmers get that gut feeling simply because most of the time, performance code is code based on a lot more informations (about the context, hardware knowledge, global architecture) than any other code in applications. Most code will only express some solutions to specific problems that are encapsulated in some abstractions in a modular way (like functions) and that means limiting the knowledge of the context to only what enter that encapsulation (like function parameters).

When you write for high performance, after you fix any algorithmic optilizations, you get into details that requires far more knowledge about the context. That might naturally overwhelm any programmer that don't feel focused enough for the task.

Answer 9

It is not so much that those things cannot coexist. The problem is that everyone's code is slow, unreadable, and unmaintainable on the first iteration. The rest of the time is spent working on improving whatever is most important. If that is performance, then go for it. Don't write spitefully awful code, but if it just has to be X fast, then make it X fast. I believe that performance and cleanliness are basically uncorrelated. Performant code does not cause ugly code. However, If you spend your time tuning every bit of code to be fast, guess what you did not spend your time doing? Making your code clean and maintainable.

Answer 10

If I can presume to "borrow" @greengit's nice diagram, and make a small addition:

|
P
E
R
F
O  *               X <- a program as first written
R   * 
M    *
A      *
N        *
C          *  *   *  *  *
E
|
O -- R E A D A B I L I T Y --

We've all been "taught" that there are tradeoff curves. Also, we have all assumed we are such optimal programmers that any given program we write is so tight it is on the curve. If a program is on the curve, any improvement in one dimension necessarily incurs a cost in the other dimension.

In my experience, programs only get near any curve by being tuned, tweaked, hammered, waxed, and in general turned into "code golf". Most programs have plenty of room for improvement in all dimensions. Here's what I mean.

Answer 11

    |
    P
    E
    R
    F
    O  *
    R   * 
    M    *
    A      *
    N        *
    C          *  *   *  *  *
    E
    |
    O -- R E A D A B I L I T Y --

As you can see...

• Sacrificing readability can increase performance -- but only so much. After a certain point, you have to resort to "real" means like better algorithms and hardware.
• Also, losing performance at the cost of readability can happen only to some extent. After that, you can make your program as much readable as you want without affecting performance. For example adding more helpful comments doesn't toll performance.

So, performance and readability are but modestly related -- and in most cases, there's no real big incentives preferring the former over latter. And I am talking here about high level languages.

Answer 12

The point is not readability should always trump efficiency. If you know from the get go that your algorithm needs to be highly efficient, then it will be one of the factors you use to develop it.

The thing is most uses cases don't need blinding fast code. In many cases IO or user interaction causes much more delay then your algorithm execution causes. The point is that you should not go out of your way to make some thing more efficient if you don't know it is the bottle neck.

Optimizing code for performance often makes it more complicated because it generally involves doing things in a clever way, instead of the most intuitive. More complicated code is harder to maintain and harder for other developers to pick-up (both are costs that must be considered). At the same time, compilers are very good at optimizing common cases. It is possible that your attempt to improve a common case means that the compiler does not recognize the pattern anymore and thus can not help you make your code fast. It should be noted that this does not mean write whatever you want without concern to performance. You should not be doing anything that is clearly inefficient.

The point is to not worry about little things that might make things better. Use a profiler and see that 1) what you have now is an issue and 2) what you changed it to was an improvement.

Answer 13

In my opinion performance should be a consideration when it's an actual problem (or e.g. a requirement). Not doing so tends to lead to microoptimizations, which might lead to more obfuscated code just to save a few microseconds here and there, which in turn leads to less maintainable and less readable code. Instead one should focus on the real bottlenecks of the system, if needed, and put emphasis on performance there.

Answer 14

Precisely because highly performing software components are generally orders of magnitude more complex than other software components (all other things being equal).

Even then it is not as clear cut, if performance metrics are a critically important requirement then it is imperative that the design have complexity to accomodate such requirements. The danger is a developer who wastes a sprint on a relatively simple feature trying to squeeze a few extra milliseconds out of his component.

Regardless, complexity of design has a direct correlation with the ability of a developer to quickly learn and become familiar with such a design, and further modifications to functionality in a complex component can result in bugs that might not be caught by unit tests. Complex designs have many more facets and possible test cases to consider making the goal of 100% unit test coverage even more of a pipe dream.

With that being said it should be noted that a poorly performing software component could perform poorly just because it was foolishly written and unnecessarily complex based on the ignorance of the original author, (making 8 database calls to build a single entity when just one would do, completely unnecessary code that results in a single code path regardless, etc...) These cases are more a matter of improving code quality and performance increases happening as a consequence of the refactor and NOT the intended consequence necessarily.

Assuming a well designed component however, it will always be less complex than a similarly well designed component tuned for performance (all other things being equal).