perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ask Bjoern Hansen <>
Subject Re: performance coding project? (was: Re: When to cache)
Date Sat, 02 Feb 2002 00:40:26 GMT
On Sat, 26 Jan 2002, Stas Bekman wrote:

> > It's much better to build your system, profile it, and fix the bottlenecks.
> > The most effective changes are almost never simple coding changes like the
> > one you showed, but rather large things like using qmail-inject instead of
> > SMTP, caching a slow database query or method call, or changing your
> > architecture to reduce the number of network accesses or inter-process
> > communications.
> It all depends on what kind of application do you have. If you code is 
> CPU-bound these seemingly insignificant optimizations can have a very 
> significant influence on the overall service performance. Of course if 
> you app, is IO-bound or depends with some external component, than your 
> argumentation applies.

Eh, any real system will be a combination.  Sure; when everything
works then it's worth finding the CPU intensive places and fix them
up, but for the most part the system design is far far more
important than any "code optimiziation" you can ever do.

My usual rhetorics: Your average code optimization will gain you at
most a few percent performance gain.  A better design can often make
things 10 times faster and use only a fraction of your memory.

> On the other hand how often do you get a chance to profile your code and 
>   see how to improve its speed in the real world. Managers never plan 
> for debugging period, not talking about optimizations periods. And while 
> premature optimizations are usually evil, as they will bait you later, 
> knowing the differences between coding styles does help in a long run 
> and I don't consider these as premature optimizations.

If you don't waste time profiling every little snippet of code you 
might have more time to fix the real bottlenecks in the end. ;-)
> All I want to say is that there is no one-fits-all solution in Perl, 
> because of TIMTOWTDI, so you can learn a lot from running benchmarks and 
> picking your favorite coding style and change it as the language 
> evolves. But you shouldn't blindly apply the outcomes of the benchmarks 
> without running your own benchmarks.


(And don't get me wrong; I think a repository of information about
the nitty gritty optimization things would be great - I just find it
to be bad advice to not tell people to do the proper design first).

 - ask

ask bjoern hansen,         !try; do();
more than a billion impressions per week,

View raw message