Stas Bekman <[EMAIL PROTECTED]> writes:
> And the results are:
>
> single_print: 1 wallclock secs ( 1.74 usr + 0.05 sys = 1.79 CPU)
> here_print:3 wallclock secs ( 1.79 usr + 0.07 sys = 1.86 CPU)
> list_print:7 wallclock secs ( 6.57 usr + 0.01 sys = 6.58 CPU)
> multi_print
> It's not slower in 5.6. "$x and $y" in 5.6 gets turned into $x . ' and '
> . $y (in perl bytecode terms).
that's not new to 5.6.0, variable interpolation in ""'s has always turned
into a concat tree, though 5.005_03 is the oldest version i have handy to
check with. and, this "$feature" can be
On Thu, 8 Jun 2000, Stas Bekman wrote:
> Stephen Zander wrote:
> >
> > > "Stas" == Stas Bekman <[EMAIL PROTECTED]> writes:
> > Stas> Ouch :( Someone to explain this phenomena? and it's just
> > Stas> fine under the handler puzzled, what can I say...
> >
> > Continuous array grow
On Thu, 8 Jun 2000, Perrin Harkins wrote:
> On Thu, 8 Jun 2000, Matt Sergeant wrote:
>
> > > The one that bugs me is when I see people doing this:
> > >
> > > $hash{"$key"}
> > >
> > > instead of this:
> > >
> > > $hash{$key}
> >
> > Those two now also result in the same code. ;-)
> >
> > B
> Sometimes it's worse than just ugly. See the entry in the Perl FAQ:
>
http://www.perl.com/pub/doc/manual/html/pod/perlfaq4.html#What_s_wrong_with_
always_quoting
>
> Not likely that anyone would be using something as a hash key that would
> suffer from being stringified, but possible. It's def
On Thu, 8 Jun 2000, Matt Sergeant wrote:
> > The one that bugs me is when I see people doing this:
> >
> > $hash{"$key"}
> >
> > instead of this:
> >
> > $hash{$key}
>
> Those two now also result in the same code. ;-)
>
> But the former is just ugly.
Sometimes it's worse than just ugly. Se
[Sorry for the delay: didn't notice this since it was sent only to the list]
Eric Cholet wrote, in part:
>
> I never advocated optimizing at the expense of the above criteria, we
> were discussing optimizations only. I certainly believe a program is a
> compromise, and have often chosen some of
On 8 Jun 2000, Stephen Zander wrote:
> As Matt has already commented, in the handler the method call
> overheads swamps all the other activities. so concat_print &
> aggrlist_print (yes, method invocation in perl really is that bad).
> When you remove that overhead the extra OPs in aggrlist_print
> "Stas" == Stas Bekman <[EMAIL PROTECTED]> writes:
Stas> Is this a question or a suggestion? but in both cases
Stas> (mod_perl and perl benchmark) the process doesn't exit, so
Stas> the allocated datastructure is reused... anyway it should be
Stas> the same. But it's not.
It
Stephen Zander wrote:
>
> > "Stas" == Stas Bekman <[EMAIL PROTECTED]> writes:
> Stas> Ouch :( Someone to explain this phenomena? and it's just
> Stas> fine under the handler puzzled, what can I say...
>
> Continuous array growth and copying?
Is this a question or a suggestion? b
> "Stas" == Stas Bekman <[EMAIL PROTECTED]> writes:
Stas> Ouch :( Someone to explain this phenomena? and it's just
Stas> fine under the handler puzzled, what can I say...
Continuous array growth and copying?
--
Stephen
"So if she weighs the same as a duck, she's made of wood.".
From: "Matt Sergeant" <[EMAIL PROTECTED]>
To: "Stas Bekman" <[EMAIL PROTECTED]>
Cc: "___cliff rayman___" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: 08 June 2000 09:23
Subject: Re: [performance/benchmark] printing techniques
: On Wed, 7
On Wed, 7 Jun 2000, Perrin Harkins wrote:
> On Wed, 7 Jun 2000, Matt Sergeant wrote:
>
> > On Wed, 7 Jun 2000, Eric Cholet wrote:
> >
> > > This said, i hurry back to s/"constant strings"/'constant strings'/g;
> >
> > Those two are equal.
>
> Yes, although it's counter-intutive there's no rea
On Wed, 7 Jun 2000, Stas Bekman wrote:
> On Wed, 7 Jun 2000, ___cliff rayman___ wrote:
>
> >
> >
> > Stas Bekman wrote:
> >
> > >
> > >
> > > Per your request:
> > >
> > > The handler:
> > >
> > > query | avtime completed failedrps
> > > ---
> What the other programmer here and I do is setup an array and push()
> our lines of output onto it throughout all our code, and print it at
> the very end. I'd be interested in seeing benchmarks of this vs.
> the other methods. I'll try to find the time to run them.
handler:
What about heredoc with the magical @{} technique for interpolating
functions?
or Text::iPerl ? I'd be interested in knwing how they stack up
o _
/|/ | Jerrad Pierce \ | __|_ _|
/||/ http://pthbb.org . | _| |
\|| _.-~-._.-~-._.-~-._@"
On Wed, 7 Jun 2000, Matt Sergeant wrote:
> On Wed, 7 Jun 2000, Eric Cholet wrote:
>
> > This said, i hurry back to s/"constant strings"/'constant strings'/g;
>
> Those two are equal.
Yes, although it's counter-intutive there's no real performance hit
from double-quoting constant strings.
The
.--[ Jeff Norman wrote (2000/06/07 at 14:27:29) ]--
|
| Frequently, it's hard to build up an entire output segment without
| code in-between the different additions to the output. I guess you could
| call this the "append, append, append... output" technique.
|
| I think it
On Wed, 7 Jun 2000, ___cliff rayman___ wrote:
>
>
> Stas Bekman wrote:
>
> >
> >
> > Per your request:
> >
> > The handler:
> >
> > query | avtime completed failedrps
> > ---
> > single_print |110 5000 0881
> > here_pri
On Wed, 7 Jun 2000, Stas Bekman wrote:
> And the results are:
>
> single_print: 1 wallclock secs ( 1.74 usr + 0.05 sys = 1.79 CPU)
> here_print:3 wallclock secs ( 1.79 usr + 0.07 sys = 1.86 CPU)
> list_print:7 wallclock secs ( 6.57 usr + 0.01 sys = 6.58 CPU)
> multi_print:
Stas Bekman wrote:
>
>
> Per your request:
>
> The handler:
>
> query | avtime completed failedrps
> ---
> single_print |110 5000 0881
> here_print|111 5000 0881
> list_print|111 5000
Frequently, it's hard to build up an entire output segment without
code in-between the different additions to the output. I guess you could
call this the "append, append, append... output" technique.
I think it would be an interesting addition to the benchmark:
sub gather_print{
my $b
On Wed, 7 Jun 2000, Jeff Norman wrote:
>
>
> Frequently, it's hard to build up an entire output segment without
> code in-between the different additions to the output. I guess you could
> call this the "append, append, append... output" technique.
>
> I think it would be an interesting addit
> > These
> > things add up, so don't you think that whatever can be optimized, should
?
>
> Wrong question, IMHO: it's what you optimize for that counts. Several
things
> come to mind that are often more important than performance and often mean
not
> optimizing for performance (these are interr
> > 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 datab
Eric Cholet wrote:
>
> These
> things add up, so don't you think that whatever can be optimized, should ?
Wrong question, IMHO: it's what you optimize for that counts. Several things
come to mind that are often more important than performance and often mean not
optimizing for performance (these
On Wed, 7 Jun 2000, Eric Cholet wrote:
> This said, i hurry back to s/"constant strings"/'constant strings'/g;
Those two are equal.
--
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
>From: "Eric Strovink" <[EMAIL PROTECTED]>
> > Of course the slowest stuff should be optimized first...
>
> Right. Which means the Guide, if it is not already so doing, ought to
> rank-order the optimizations in their order of importance, or better,
their
> relative importance. This one, it appe
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'r
Eric Cholet wrote:
> Of course the slowest stuff should be optimized first...
Right. Which means the Guide, if it is not already so doing, ought to
rank-order the optimizations in their order of importance, or better, their
relative importance. This one, it appears, should be near the bottom o
> > 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
> g
[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 +
On Wed, 7 Jun 2000, Stas Bekman wrote:
> Following Tim's comments here is the new benchmark. (I'll address the
> buffering issue in another post)
>
> use Benchmark;
> use Symbol;
>
> my $fh = gensym;
> open $fh, ">/dev/null" or die;
>
> sub multi_print{
> print $fh "";
> pr
33 matches
Mail list logo
