in reply to Re: The Rules of Optimization Club
in thread The Rules of Optimization Club

I see far too many people trying to improve their execution speed when they have no business doing so.

The node that prompted my posting the Rules of Optimization Club was this one (Print Vs Return In a Subroutine) where the writer wanted to know if it was faster to use print or return. If he wants real speed, he can call exit, too.

The PHP world especially seems to be filled with people who worry about whether it's faster to use interpolation or concatenation to build strings, while tweaking a program that makes SQL queries against unindexed tables and returns the results over the Internet.

It is for these people that the Rules of Optimization Club are most intended.

xoxo,
Andy

Replies are listed 'Best First'.
Re^3: The Rules of Optimization Club
by tinita (Parson) on Apr 01, 2012 at 13:41 UTC
    I agree with that. it's just that I read people quoting the famous "premature optimization" thing way too often, and most of the time they forget to mention (or probably to even read) the rest of the quote.
    So I got really allergic to any "don't optimize" statements =)
[reply]
      Nobody is saying don't optimize. In fact, I've never seen anyone say that "you should never optimize your code." If you can point me to someone who says that, I'd love to see it.

      It's all about what "premature" is.

      If your code is broken, then it's premature.

      If you don't know the costs of your code, it's premature.

      xoxo,
      Andy

[reply]
        Nobody is saying don't optimize.
        If you don't want to give that expression, I suggest you don't start posts with
        The first rule of Optimization Club is, you do not Optimize.
        Because you could have fooled me.

        If your code is broken, then it's premature.
        Eh, no. That's way to general. If a landslide just dumped a few metric tons of mud on my driveway, I'm not going to measure my progress while I'm digging with a spoon. I'll optimize that away right from the start. There's no point in continuing a work in progress of a fix if it's going to be too slow. Even if the fix leads to unbroken code. It's better to turn back and optimize *now* before spending the effort to reach an unsatifying situation.

        While I agree that many optimizations are premature, I don't agree this is always true.

[reply]

In Section Meditations