Hacker News Reader

Comment by lojack | Hacker News Reader

His full quote is a little less prone to abuse

> Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.

Premature optimization isn't bad, premature micro optimization is bad. You should also be thinking about optimization that results in better architecture and architectural decisions that make it easier to optimize in the future.

View on HN

Yeah, I get frustrated that few people actually post the full quote, because, with the context, it means something completely different to young ears.

The full quote makes me think: "You should identify the critical paths of your system early." The shortened quote makes me think: "Deal with performance later."

Pretty big difference in meaning.

Personally, I think it's more about balancing trade offs. You need to have some semblance of target performance needs. Bad architecture can be hard to overcome later.

Most decisions are small, but can lead to compounding effects. Personally, I think one should also avoid premature pessimissation as well. No one in their right mind would use bubble sort over quick sort, for instance (not saying quick sort is the best algorithm, but it's better than bubble sort). One pet peeve I have in C++ is when I see people initializing a std::string with a literal empty string instead of using the default constructor. The default constructor is usually a memset or initializing 3 pointers. Initializing with an empty literal involves a call to strlen, malloc and strcpy. I've yet to see a compiler optimize this. May not seem like a big deal, but considering one of the most frequently used data types is a string, it adds up a lot. Most of the applications I've worked on show std::string methods and constructors as hotspots when profiled (back office financial systems).

I agree one should avoid premature micro-optimization, but that you can also avoid premature pessimissation.

Reply on news.ycombinator.com