Premature optimization is the root of all evil | Hacker News Reader

Premature optimization is the root of all evil

c2.com

13 pointsmorganwilde20 comments

Premature optimization used to mean unnecessarily writing assembly or borderline obfuscated C in the name of performance, which led to programs being difficult to comprehend, hence it being the root of all evil. Today this has been perverted to mean "hey, buddy, if you think about performance you're optimizing prematurely!"

People need to learn their history before throwing out such maxims.

Perhaps misguided optimisation would be a better term, and seems to be what Knuth is driving at. People do spend a lot of time worrying about all the wrong things, many of which a decent optimising compiler will take care of.

Efficient code should always be on your mind, but actual optimisation probably ought to be done with the aid of a profiler rather than a hunch a 'clever' way of doing something.

Agreed - I've seen cases where someone obsesses about shaving milliseconds off a tight loop whilst using a profiler would reveal that the real bottleneck is the code called just before entering the loop.

Premature optimisation is optimisation without knowing what needs to be optimised.

It always baffled me to hear that quote, and then notice the examples in the art of programming are all done in ASM.

We live in a an age where computers are so fast it's considered acceptable to be an engineer and just blurb out code and show people that "shit just works".

That quote is indeed very misleading, because at the time, CPU were still getting faster frequencies, so optimizing problems were solving themselves.

Today we face a problem where the faster algorithms are the one we need, because multithreading is hard, and also because there is no real tech to do clustering out of the box.

I'll always smirk when I look at this quote, and look at spidermonkey, v8, chrome, and carmack's

You live a sheltered life! In games and other development cultures where performance is a traditionally staple argument, C++ cowboys say things things like "We can't have an scripting API method that returns a list of component names since it will be slow and it will malloc"

Since the same guys are doing the crunch phase optimizations, their prejudices have a survival bias which carries a lot of apparent "battle hardened" weight

In my mind a "sheltered life" is something completely different. It's when you can get away with using 20 servers instead of 2, based solely on unproven and unrealistic productivity claims about dynamic languages and certain frameworks.

I've seen that perverted to design absolute nonsense and as a defense say: "hey, we don't do premature optimization here!".

I'm glad this came up; I've been thinking about it for a while.

When I first started programming professionally and read this quote, I thought it didn't really apply to me. I do a lot of low-traffic webapps and never really felt like I did much trade-off with premature optimization. It certainly sounded strong to say that pre-mature optimization was the root of all evil. Hell, I messed up so many other things that I would have picked any one of them and thought it to be more of a problem. But I respected the person saying it, so I kept it in the back of my mind.

Then I had an epiphany. Pre-mature optimization isn't just about performance, and it doesn't even have to be about only programming. In your business, are you focusing on automating something that will only save a miniscule amount of time? Are you building a feature that will rarely ever be used? Sounds like pre-mature optimization to me. And the problem is not that the end-product won't be better; the problem is the opportunity cost. You're trading off a whole host of other things that could be worked on instead.

Pre-mature optimization for me comes down to reassessing where I am at every stage of building a project and asking myself: am I focused on the right thing? Because if not, I'm wasting my time.

I think what Knuth/Hoare/whoever was trying to say here is - solve the problems you know you have. The key point is that the "know" should be demonstrable knowledge (as opposed to asserting "I know" with authority), in which case it would be justifiable to extend the principle to "solve the problems you know you have or will have".

This sounds like the most appropriate assertion in this case. I doubt Knuth suggested writing inefficient code, it's just that first comes the stuff you know (as you mentioned), then - if required - improvements.

It boils down to common sense. My approach is to try to writing the code reasonably efficient, but initially, readability, maintainability and simplicity take precedence over performance. I wouldn't write a more hacky or complex code just for the sake of performance before I KNOW there's a problem.

Nothing actionable in the article nor in these comments. Some folks use hashtable as a default container - is that premature optimization? Wouldn't a vector do? Which one is 'evil' and which one is right?

This came up when watching a CS193p lecture 2 on iTunesU (Winter 2013).

Bad optimization is bad. Of course.

You're missing the point.

The point is that in many cases, you should optimize for readability and simplicity first, and optimize for performance only if it's likely to become an issue. If you optimize for performance first, you may well have massively increased your cost of development for incremental performance gains that you could have got by throwing a bit more hardware at the problem.

That's what premature means.

It's not. Poor communication is.

Please explain, because I find that difficult to appropriate to projects worked on by a single person.

For a single person? Well it depends where the requirements are coming from, and how often the checkin with that other person are coming to compare what is being done with what is expected to be done.

All bets are off for a single person project.

Reply on news.ycombinator.com