Re: The Rules of Optimization Club

[tinita]

I hope you realize how ironic this sounds in this forum. my typical usage here is: click on a thread, than switch tab to a different forum/rss feed/whatever, read 2 or 3 articles, then switch back to perlmonks where the thread has finished loading ;-)

first: I think everyone would agree that optimizing without having a clue is a waste of time. playing around with Benchmark and Devel::NYTProf can be really enlightening.
if you don't have a clue about algorithms and complexity you still can write programs that do what you want, that are well written in terms of maintainability and "fast enough".

but: if nobody ever cared about writing highly optimized perl modules, nobody would want to write applications and websites with it.

I'm actually sick of people warning about premature optimization over and over. in the last weeks I have been optimizing my forum software which has been running live for over three years. I did many different optimizations, and by logging the different request times and viewing them in munin graphs I could clearly see what kind of optimizations were more successful and which less.
I can estimate that some optimizations will be only worth if the website had more traffic. But that's no reason for not doing it. It's a software that I want to call "scalable".
I was talking about some of my thoughts in an IRC channel, and one person said to me that I was doing premature optimization. wtf?

so, yes: measure before or during optimization. if you are experienced though, often you don't need to measure beforehand.
but stop warning people about optimization in general.

[petdance]

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.

[tinita]

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 =)

[petdance]

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.

[BrowserUk]

but stop warning people about optimization in general.

Hal-ley-loo-yaah!

My first reaction to accusations of "premature optimisation", is that the accuser is: a) aware of the limitations of their knowledge of the required techniques; b) aware of the techniques, but too lazy to pursue them; 3) a marketeer who'd rather sell you his latest gizmo, gadget -- be they software or hardware -- than show you how to make more effective use of the one you brought from him last year.

Permute from the three.

S'not always the case, but more often than not.