[benchmark code snipped]
> > single_print: 4 wallclock secs ( 2.28 usr + 0.47 sys = 2.75 CPU)
> > here_print: 2 wallclock secs ( 2.45 usr + 0.45 sys = 2.90 CPU)
> > list_print: 7 wallclock secs ( 7.17 usr + 0.45 sys = 7.62 CPU)
> > multi_print: 23 wallclock secs (17.52 usr + 5.72 sys = 23.24 CPU)
> >
> > The results are worse by the factor of 1.5 to 2, with only
> > I<'list_print'> changed by very little.
> >
> > 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.
>
> Perhaps this section should be (re)moved into a posterity section, for it
> seems fairly un-informative to me.
Matt, Have you seen all these scripts with hundreds of print statements?
This section comes to open the eyes of programmers who tend to use this
style.
Obviously, that if write the normal code the real choice doesn't really
matter, unless you do lots of printings.
But, remember that each of the performance sections of the guide can be
deleted following your suggestion. Each section tackles a separate
feature/technique. The overall approach only matters. My goal is to show
programmers how to squeeze more out of their code, definitely I'm not
talking to people who run guestbooks code.
Take for example Ask and Nick from ValueClick. Let's ask them whether
these techniques matter or not. With 70-80M requests served daily each
saved millisecond counts. Ask? Nick?
What do you think?
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC
http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
