Clean readable code vs fast hard to read code. When to cross the line?

Question

When I write code I always try to make my code as clean and readable as possible.

Every now and then there comes a time when you need to cross the line and go from nice clean code to slightly uglier code to make it faster.

When is it OK to cross that line?

Answer 1

You cross the line when

• You have measured that your code is too slow for its intended use.
• You have tried alternative improvements that don't require mucking up the code.

Here's a real-world example: an experimental system I am running was producing data too slowly, taking over 9 hours per run and using only 40% of CPU. Rather than mess up the code too much, I moved all the temporary files to an in-memory filesystem. Added 8 new lines of non-ugly code, and now CPU utilization is above 98%. Problem solved; no ugliness required.

Answer 2

When you've profiled the code and verified that it is actually causing a significant slowdown.

Answer 3

It's a false dichotomy. You can make code fast and easy to maintain.

The way you do it is write it clean, especially with as simple a data structure as possible.

Then you find out where the time drains are (by running it, after you've written it, not before), and fix them one by one. (Here's an example.)

Added: We always hear about tradeoffs, right, such as a tradeoff between time and memory, or a tradeoff between speed and maintainability? While such curves may well exist, it should not be assumed that any given program is on the curve, or even anywhere near it.

Any program that is on the curve can easily (by giving it to a certain kind of programmer) be made both much slower, and much less maintainable, and then it will be nowhere near the curve. Such a program then has plenty of room to be made both faster and more maintainable.

In my experience, that's where lots of programs start out.

Answer 4

Whenever the estimated cost of lower performance in the marketplace is greater than the estimated cost of code maintenance for the code module in question.

People still do twisted hand-coded SSE/NEON/etc. assembly to try and beat some competitor's software on this year's popular CPU chip.

Answer 5

When it is throw-away code. I mean that literally: when you write a script to perform a one-off calculation or task, and know with such certainty you will never have to do that action again that you can 'rm source-file' without hesitation, then you may choose the ugly route.

Otherwise it is a false dichotomy--if you think you need to make it ugly to do it faster, you're doing it wrong. (Or your principles about what is good code need revising. Using goto is in fact quite elegant when it is the proper solution to the problem. It rarely is however.)

Answer 6

In my OSS existence I do a lot of library work aimed at performance, that is deeply tied to the caller's data-structure (i.e. external to the library), with (by design) no mandate over the incoming types. Here, the best way to make this performant is meta-programming, which (since I'm in .NET-land) means IL-emit. That is some ugly, ugly code, but very fast.

In this way, I happily accept library code may be "uglier" than application code, simply becuase it has less (or maybe no) control over the inputs, so needs to achieve some tasks through different mechanisms. Or as I expressed it the other day:

"coding over the cliff of insanity, so you don't have to "

Now application code is slightly different, as that is where "regular" (sane) developers are typically investing much of their collaborative/professional time; the goals and expectations of each are (IMO) slightly different.

IMO, the answers above that suggest it can be fast and easy to maintain are referring to application code where the developer has more control over the data-structures, and isn't using tools like meta-programming. That said, there are different ways of doing meta-programming, with different levels of insanity and different levels of overhead. Even in that arena you need to choose the appropriate level of abstraction. But when you actively, positively, genuinely want it to handle unexpected data in the absolute fastest way; it may well get ugly. Deal with it ;p

Answer 7

Since the question says "fast hard to read code", the simple answer is never. There's never an excuse for writing code that's hard to read. Why? Two reasons.

1. What happens if you're hit by a bus on your way home tonight? Or (more optimistically, and more typically) taken off this project and reassigned to something else? The small benefit you imagine you've made with your tangled mess of code is totally outweighed by the fact that nobody else can understand it. The risk this poses to software projects is hard to overstate. I worked once with a major PBX manufacturer (if you work in an office you probably have one of their phones on your desk). Their project manager told me one day that their core product - the proprietary software that turned a standard Linux box into a fully-feature phone exchange - was known inside the company as "the blob". Nobody understood it any more. Every time they implemented a new feature. they'd hit compile then stand back, close their eyes, count to twenty, then peek through their fingers to see if it worked. No business needs a core product they no longer control, but it's a frighteningly common scenario.
2. But I need to optimise! OK, so you've followed all the excellent advice in other answers to this question: your code is failing its performance test cases, you've profiled it carefully, identified the bottlenecks, come up with a solution... and it's going to involve some bit-twiddling. Fine: now go ahead and optimise. But here's the secret (and you may want to sit down for this one): optimisation and reduction in source code size are not the same thing. Comments, white space, brackets and meaningful variable names are all huge aids to readability that cost you absolutely nothing because the compiler will throw them away. (Or if you're writing a non-compiled language like JavaScript - and yes, there are very valid reasons to optimise JavaScript - they can be dealt with by a compressor.) Long lines of cramped, minimalist code (like the one muntoo has posted here) have nothing to do with optimisation: that's a programmer trying to show how clever they are by packing as much code into as few characters as possible. That's not clever, it's stupid. A truly clever programmer is one who can communicate their ideas clearly to others.

Answer 8

Clean code is not necessarily exclusive with fast-executing code. Normally difficult-to-read code was written because it was quicker to write, not because it executes any faster.

Writing "dirty" code in an attempt to make it faster is arguably unwise, since you don't know for certain that your changes actually improve anything. Knuth put it best:

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified."

In other words, write the code clean first. Then, profile the resulting program and see if that segment is, in fact, a performance bottleneck. If so, optimize the section as necessary, and be sure to include plenty of documentation comments (possibly including the original code) to explain the optimizations. Then profile the result to verify that you actually made made an improvement.

Answer 9

Don't forget you can make hard-to-read code easy to understand by appropriate documentation and commenting.

In general, profile after you've written easy-to-read code that does the desired function. Bottlenecks might require you to do something that makes it look more complicated, but you fix that by explaining yourself.