On Wed, 7 Jun 2000, Eric Cholet wrote:
> > > So if you want a better performance, you know what technique to use.
> >
> > I think this last line is misleading. The reality is that you're doing
> > 500,000 iterations here. Even for the worst case scenario of multi_print
> > with no buffering you're managing nearly 22,000 outputs a second. Now
> > granted, the output isn't exactly of normal size, but I think what it
> > comes down to is that the way you choose to print is going to make almost
> > zero difference in any real world mod_perl application. The overhead of
> > URL parsing, resource location, and actually running your handler is going
> > to take far more overhead by the looks of things.
>
> I don't understand what you're getting at. Does this mean that something
> shouldn't be optimized because there's something else in the process that
> is taking more time? For example I have a database powered site, the slowest
> part of request processing is fetching data from the database. Should I
> disregard any optimization not dealing with the database fetches ? These
> things add up, so don't you think that whatever can be optimized, should ?
> Of course the slowest stuff should be optimized first, but that doesn't
> mean that other optimisations are useless.
Of course you can optimize forever, but some optimizations aren't going to
make a whole lot of difference. This is one of those optimizations,
judging by these benchmarks. Let Stas re-write this benchmark test as a
handler() and see what kind of difference it makes. I'm willing to
bet: barely any between averages.
Perhaps I was a little strong: Lets not deprecate this part of the guide,
just provide some realism in the conclusion.
--
<Matt/>
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org http://xml.sergeant.org
