I like that you've brought this up. You've raised the all-important practical side of software development. Life is about choices - selecting one thing over another. If the time to get the project live is constant, then you may need to choose between an implementation that works, and one that is fast. The warning against premature optimisation is well-deserved: it's far better to be slow and right than it is fast and wrong. I can always throw a faster CPU at the problem to speed it up, but I can't always throw hardware at a problem to correct the answer. That requires programmer time - which is far more expensive.

The product I work on has a key component of speed. It must respond within a certain amount of time - and that amount is always lessening. And, just for fun, we keep the hardware constant (or we adjust our requirements based on the new hardware). But then, to meet that requirement, we actually pay a group of people to focus solely on finding bottlenecks and reducing, if not outright eliminating, them. That's just the management-recognised cost of performance. We pay 20 people to get it right, and 2 people to get it fast. Trading off money for performance in the same amount of time.

If you don't have the budget to get everything done on time, working, and fast enough, I would have to drop "fast enough" every time. It's much easier to make a slow, working application fast than a fast, non-working application correct.

There are some simple things one can do to keep from getting slow in the first place, e.g., in C++, I encourage my coworkers to do: 

  const size_t len = strlen(some_string) + strlen(other_string) + 1;
  char* copy = new char[len];
  memcpy(copy, '\0', len);

[download]
rather than doing that strlen twice each. (Well, actually, I encourage them to put the new and memcpy into an inline function.) Is that premature? Perhaps - but I look at it as a way to reduce the chance of errors: rather than duplicating code, I'm refactoring it. In a way that allows the compiler to make its own optimisations. That it allows the compiler to optimise isn't a premature optimisation - it's just a smarter way to do something which happens to be a faster alternative.

I suppose that means that even within "premature optimisation", there is a lot of fuzziness and leeway as to what constitutes "premature". Or even "optimisation".

In reply to Re^4: Optimisation (global versus singular) by Tanktalus
in thread Optimisation isn't a dirty word. by BrowserUk

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.