

Premature optimization is the root of all evil - morganwilde
http://c2.com/cgi/wiki?PrematureOptimization

======
kintamanimatt
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.

~~~
Nursie
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.

~~~
rahoulb
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.

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

------
d23
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.

------
aufreak3
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".

~~~
morganwilde
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.

------
drorweiss
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.

------
JoeAltmaier
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?

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

------
illumen
Bad optimization is bad. Of course.

~~~
peteretep
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.

------
nodata
It's not. Poor communication is.

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

~~~
nodata
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.

~~~
ollysb
All bets are off for a single person project.

