4 ms·
The notion of 'premature optimisation is evil' is partly to blame; It's not a terrible rule, but it's much better with conditions applied. i.e. apply some intel
by redcalx 11y ago
The notion of 'premature optimisation is evil' is partly to blame; It's not a terrible rule, but it's much better with conditions applied. i.e. apply some intelligence/judgement to where you use optimisation rather than just lazily following some rule.
- richmarr 11y agoIsn't that intelligence/judgement wrapped up in the interpretation of 'premature'?
- redcalx 11y agoFair point. I suspect that that subtlety to the rule is often lost to the reader. Perhaps a rewording is in order that puts emphasis on the conditional part (i.e. what constitutes premature)
- vezzy-fnord 11y agoOr you could just reference the full quote, which reveals a remarkably different context than what is commonly interpreted.
- redcalx 11y agoHa! But that is the quote that gets repeated, i.e. it's been 'optimised' to aid viral/meme transfer, but not optimised in meaning :)
- kazinator 11y agoFirstly, lack of optimization for software size or execution time is a form of optimization: it's optimization of someone's time. Not writing a compiler for your scripting language saves you years. Not choosing carefully what features to include in a program, or what packages in a system image: design time saved again. It also saves considerable time if a user wants the program to do something, and by golly, "look, they thought of that already: there is a feature for it!" Seconds later, the user is just doing whatever they need instead of surfing the web for workarounds or calling support. Having all the features also increases the flexibility of customization: you have more choices about what you can remove to create smaller images which have specific feature sets. You can hardly remove anything from a minimal image to make a specialized custom image. I.e. by not making a program as minimal as possible, compact as possible or fast as possible, you are making some kind of trade off. Though the program is worse in some regard, there exist parameters (of something, not necessarily the program) which have gotten better: if you think about it a little, you can identify what those parameters are. The worsening in some of those parameters in a "bad trade" is what makes premature optimization "evil".
- redcalx 11y agoI agree with the general point, however, I believe it's commonplace for software to be poor on those other metrics you mention too, i.e. the one metric that /has/ been optimised is development cost. All of the optimal outcomes define a Pareto front, i.e. spend time optimising feature A versus speed, cost, etc. But as soon as you bring in low(er) quality engineers you're moving away from the Parento front, probably quite significantly so.
- kazinator 11y agoI.e. not only will there be bloat, but users won't find the features they need, it will be delivered late, and with bugs, etc. :)
- mondoshawan 11y agoPremature optimization is evil -- when you don't have a design for how your system will work. The axiom is only valid in those cases because if you've designed your system well, the points for optimization are already obvious and the code can be written mostly optimized the first time round.