Knuth was wrong.

Post Reply New Topic

I'm talking about the "premature optimizations are evil" speech. So many things are wrong with it.

1) You can't fix big inefficiencies at the last stage of development.
2) Those 97% of the small inefficiencies add up, and would take forever to fix.
3) Premature optimizations don't cause glitches, programming mistakes do.
4) Writing optimized code often takes less time to write than unoptimized code.

Knuths view of premature optimizations are still spot on. He didn't mean that you should write messy code to begin with, but that you should wait until the final stages to remove minor bugs and try to get better performance. "Make it work, make it good, make it fast".

If you follow the SOLID principles from the start, your code will look clean, you can indeed fix big inefficiencies, and you'll be able to optimize it better in the end. If you try to optimize prematurely, you'll run great risk of ruining the functionality. Premature optimizations are one of the reasons why programmers without degrees write ugly code.

That depends on the type of inefficiencies. Design issues are hard to fix at a later stage, but simple functions can easily be optimized at a later stage.


Not if you follow good programming practices and optimize where it's needed.

But premature optimizations can obsfacturate the code, making it harder to read and understand. Code that's hard to read and understand is also hard to maintain. Which in turns can cause a lot of issues.

You wouldn't implement [/quote]fast inverse square root before making sure everything else works. Otherwise you'd end up not knowing if the mistake is in the fast inverse square root or somewhere else.


Optimizing properly can take a lot of time too. Especially if you want to tweak and tweak a function you use a lot.

I think the point here is that, as Kurgan says, focus on writing good code, following SOLID principles. If you code is easy to read and understand, it's easy to optimize.

It's also hard to know where to optimize before you can run the code through a profiler. Don't guess what the inefficiency is and spend hours trying to optimize it. And
don't help the compiler.

I assume that what you mean by "big efficiencies" is what I think of as "poor code".

If you write decent code that compartmentalizes functionality, then you should be able to optimize what needs to be optimized later.

Years ago, I was given someone else's project with the directions to finish debugging the code when the author was promoted to be head of the project. The problem was that the code needed to be finished but that it needed to be scrapped and rewritten from scratch. It was poorly done code that could not be satisfactorily fixed. I could have rewritten it from scratch with a fraction of the time and effort it would have taken to fix the bugs in it.

When I finally gave up and left, someone else got the task of "fixing it". He took a completely different approach to the problem. He was already aware that the code was bad and needed to be replaced. He had the added advantage that the project manager who wrote the code originally was quickly losing his status in the company. So he surreptitiously rewrote the code from scratch. After a few months, the new code was ready for production.

But this wasn't a problem of optimization. It was a problem of producing good code from bad. It can't be done.

So my only real frame of reference for what you said makes me think that the "big inefficiencies" you are thinking of is really just bad code. If that is the case, then you are correct -- fixing bad code is a waste of time and effort. Optimization is not about fixing bad code.

Write good code from the start and then optimize what needs to be optimized.