3 ms·

Oh please, not the Knuth's "principle" again. Optimization is a skill, it's not evil. A skilled engineer can build sufficiently good systems without wasting muc

• lojack 8y ago
  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.
  • mr_tristan 8y ago
    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.
    • hermitdev 8y ago
      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.
• kickopotomus 8y ago
  I think the issue is that people often conflate optimization with simplification. You can, and should, try to simplify the problem space early on in the project life cycle but don't waste your time on things like comparing runtime performance of string pattern matching algorithms.
• largecoredump 8y ago
  The problem with the Knuth quote is that apparently people have turned the word "premature" into a synonym for "up-front." No, that's not what it means. Knuth is not saying that you should code (shit-out) the whole system naively and then try to find out where the bottlenecks are, as this dumb post suggests. Anybody that knows about the Knuth programming contest story would know he would be the last to endorse this. Premature literally means spending time on optimizing individual things before their need becomes apparent. It doesn't mean you should delay optimizing a system design from day 1.