| > I would love to get all these "Performance First! Its so easy" engineers in a room for a week. Except that's not the argument in the comment you're reacting to. Here's what the comment actually said: > Anyone with a reasonable amount of experience is often able to look ahead - well before any code is written - and see how performance could be better if road A is taken instead of road B. In other words, some optimizations come with no significant cost. As a banal, perhaps exaggerated example, if you're writing code that needs to store data in a collection and you know that it's going to perform random access to that data on a regular basis, you're not likely to pick a linked list over some kind of array. What @abraae is criticizing is the practice of asserting "best practices" that are likely to be taken out of context, widely propagated and misinterpreted. Knuth's famous assertion "premature optimization is the root of all evil" is an excellent example. People love quoting it, but few seem to take into account the context, to the point that it has been largely forgotten. Here's the quote in its context: 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%. To be clear, it's not Knuth's fault that people are taking his very rational and sensible advice and reducing it to "yeah, you should totally disregard performance when first writing your code". This is not about pointing fingers and assigning blame, it's about being responsible when offering advice. Knuth's advice was reasonable and nuanced, and it still got taken out of context and reduced to something different and arguably harmful. Now look at Gabriel's advice, which is arguably a lot easier to take out of its context and misinterpret, and imagine the consequences it could have. That is what @abraae is reacting to. EDIT: There's another thing that really, really bothers me about your reply: > Rule #1 of any business: Sales cures all. This, right here, is what I personally feel is wrong with software nowadays. It's how we end up with poorly written, bloated, bug-ridden, unstable, unreliable, insecure crap that we end up using anyway, because there's no better alternative. |
See https://medium.com/@jaredpochtar/on-performance-and-software... and the full section on https://medium.com/@gabriel_20625/technical-lessons-from-bui...
> Most of the code we wrote was fast enough (<2ms) that making it faster wouldn’t be noticeable, so it would definitely be a waste of time to optimize. Making code that’s 0.1% of your runtime 100x faster only makes your latency <1% lower.