Can SOLID principles be used for high-performance code? [closed]

Question

I used to work on a team that specialized in high-performance C++ code. In an effort to squeeze every bit of performance out of the code, non-obvious and subtle tricks were used, making it difficult to read. Robert C. Martin's "Clean Architecture" book promotes the SOLID architecture principles: decoupling of code through dependency inversion, single-use principle, among others. The extra layers and strictly adhering to interfaces seems like it could get in the way of certain techniques for better performance. Does one have to make a choice between high-performance and SOLID architecture?

Answer 1

Does one have to make a choice between high-performance and SOLID architecture?

Of course the only sensible answer to this question can be, it depends on what you mean by high-performance. But that answer implies that SOLID and performance are somehow related.

It's fair to say that OOP principles and patterns in general are not focused on performance, i.e. they are not intended with the explicit purpose of increasing or even maintaining any specific level of performance. It may even be fair to say that the most common mechanisms of achieving these OOP goals will decrease performance (however slightly) in most common OO languages.

On the other hand, it's also fair to say that performance is not a particular goal in most of the documentation concerning these practices; so there's nothing to stop you from adapting them to performance-critical applications.

I find it useful to modify the question somewhat, in order to provoke interesting answers. For example,

Is hyper-optimized code as readable as code that is allowed to make some performance concessions?

Clearly not. Readability, maintainability, extensibility, etc. are not free. Why should they be? There is no free lunch in software engineering. Everything is tradeoffs. If you cannot sacrifice an ounce of performance, why should you expect maximum code quality? Performance is the language of machines. Quality is the language of humans. There will always be an impedance mismatch between these two.

The one thing you should not do is draw the conclusion that if performance can be increased by violating principles, then principles can be ignored. It is exceedingly rare to find an application where performance is the main concern. In most applications where people think it is, it is not. Even in applications where performance is critical, it is not the only concern. For example, instantaneous computation has little value if the computation is wrong. The computation is far more likely to be wrong when average programmers cannot understand it.

Everything in software engineering is tradeoffs. Just don't confuse relative value with absolute value. The answer to the title is yes, but you may need to target which principles you apply, and where. Performance does not absolve you of considering quality. It only makes your job more complicated, because you must consider performance in addition to quality.