[RANT]
quote:
[...] Premature Optimization [...]
I regularily get neurological seizures, when I see/read/hear this term. This whole concept of "premature optimization", which seems to be so loved by the academic crowd, is one of the most idiotic concepts I know of. Just after hungarian notation. Welcome to the the world of "modern" software development: extremely slow and bloated code, that takes ten times more space than it should, and executes ten times slower than it could. Great. And often this is not the result of inherently bad design, but the result of simple little errors from the "premature optimization" brainwashing.
quote:
Three rules of optimization, stolen from someone or other here (feel free to speak up and take credit):
1. Don''t optimize.
2. (for advanced programmers) Don''t optimize yet.
3. Use a profiler.
I fully agree with 3, no question about that. I do not entirely agree with 2. There comes a point in your programming experience, where you instinctively know, that a certain piece of code is going to be a bottleneck. For example, let''s take a string or a vector class. You
know that it is going to be used throughout your code. Emphasis is on the
amount of potential use: if some piece of (library) code is going to be extensively used, then chances are, that it will sooner or later end up in time critical parts. It can not be wrong to optimize such code beforehand. In fact, it will even increase your productivity. And I certainly do not agree with point 1. Actually, I think that point 1 is one of the main reasons for low-quality, slow and bloated code.
And just to clear up another common mistake: optimized code does not need to be ugly, or unmaintainable. Optimized code doesn''t necessarilly mean ASM either. Optimized code is a way of thinking and organizing your algorithmic structures. Optimizing is also programming with speed and efficiency in mind. Optimized programming is not using a std::map, if an std::vector would do it. Or not using operator new() in a string class for small elements, but a pool allocator. It''s choosing the right tools (ie. structures and algorithms) to do the job. Unfortunately, lots of people lose sight of that: they write bloated and slow code, with the idea of subsequent optimization in the head. "We''ll optimize it later, first it needs to run". Bullshit. We all know, that it is never going to be optimized later - if the product works, it is considered ready for shipping. Try to convince the marketing departement, that the apparently fully opeartional (but slow) software needs another two month optimization pass. Good luck.
[/RANT]