5 ms·
Premature optimization is the root of all evil
- morganwilde 13y agoThis came up when watching a CS193p lecture 2 on iTunesU (Winter 2013).
- nodata 13y agoIt's not. Poor communication is.
- morganwilde 13y agoPlease explain, because I find that difficult to appropriate to projects worked on by a single person.
- shin_lao 13y agoI've seen that perverted to design absolute nonsense and as a defense say: "hey, we don't do premature optimization here!".
- deleted 13y ago[deleted]
- drorweiss 13y agoIt 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.
- kintamanimatt 13y agoPremature 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 13y agoPerhaps 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 13y agoAgreed - 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.
- fulafel 13y agoYou 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
- fauigerzigerk 13y agoIn 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.
- illumen 13y agoBad optimization is bad. Of course.
- JonnieCache 13y agoThat's what premature means.
- peteretep 13y agoYou'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.
- aufreak3 13y agoI 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 13y agoThis 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.
- d23 13y agoI'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.
- JoeAltmaier 13y agoNothing 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?