Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
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?
You cross the line when
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.
foo and rename it foo_ref - typically it lives immediately above foo in the source file. In my test harness I call foo and foo_ref for validation and relative performance measurement.
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.
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
When you've profiled the code and verified that it is actually causing a significant slowdown.
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.
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.
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.)
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.
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.
To me it's a proportion of stability (as in cemented in concrete, clay baked in the oven, set in stone, written in permanent ink). The more unstable your code is, as in the higher the probability that you'll need to change it in the future, the more easily pliable it needs to be, like wet clay, to stay productive. I also emphasize pliability and not readability. To me the ease of changing code is more important than the ease of reading it. Code can be easy to read and a nightmare to change, and what use is being able to read and easily understand implementation details if they're a nightmare to change? Unless it's just an academic exercise, typically the point of being able to easily understand code in a production codebase is with the intent of being able to more easily change it as needed. If it's difficult to change, then a lot of the benefits of readability go out the window. Readability is only generally useful in the context of pliability, and pliability is only useful in the context of instability.
Naturally even the most difficult to maintain code imaginable, regardless of how easy or hard it is to read, doesn't pose a problem if there's never a reason to change it, only use it. And it is possible to achieve such a quality, especially for low-level system code where performance often tends to count the most. I have C code I still use regularly which hasn't changed since the late 80s. It hasn't needed to change since then. The code is fugly, written in the bit-fiddling days, and I barely understand it. Yet it's still applicable today, and I don't need to understand its implementation to get plenty of use out of it.
Thoroughly writing tests is one way to improve stability. Another is decoupling. If your code doesn't depend on anything else, then the only reason for it to change is if it, itself, needs to change. Sometimes a minor amount of code duplication can serve as a decoupling mechanism to dramatically improve stability in a way that makes it a worthy trade-off if, in exchange, you get code which is now completely independent of anything else. Now that code is invulnerable to changes to the outside world. Meanwhile code that depends on 10 different external libraries has 10 times the reason for it to change in the future.
Another helpful thing in practice is to separate your library from the unstable parts of your codebase, possibly even building it separately, as you might do for third party libraries (which likewise are meant to just be used, not changed, at least not by your team). Just that type of organization can prevent people from tampering with it.
Another is minimalism. The less your code tries to do, the more likely that it can do what it does well. Monolithic designs are almost permanently unstable, since the more and more functionality gets added to them, the more incomplete they seem.
Stability should be your primary goal whenever you aim to write code that's inevitably going to be difficult to change, like parallelized SIMD code which has been micro-tuned to death. You counteract the difficulty of maintaining the code by maximizing the likelihood that you won't have to change the code, and therefore won't have to maintain it in the future. That brings maintenance costs down to zero no matter how difficult the code is to maintain.
