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: 10
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. ;-)
But the former is just ugly.
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 growth and copying?
Is
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 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
---
single_print |110
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 real performance
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 Jun 2000, Stas Bekman 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?
--
Stephen
"So if she weighs the same as a duck, she's made of wood."... "And
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? but in both
"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 was a
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
Stephen Zander wrote:
As Matt has already commented, in the handler the method call
overheads swamps all the other activities.
Just to clarify: that's only important if you are doing very few other
activities, or if those other activities also include a high percentage
of method calls:
On Thu, 8 Jun 2000, Barrie Slaymaker wrote:
Stephen Zander wrote:
As Matt has already commented, in the handler the method call
overheads swamps all the other activities.
Just to clarify: that's only important if you are doing very few other
activities, or if those other activities
[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 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. See the entry in
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
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 "!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML//EN\"";
print $fh "HTML";
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 "!DOCTYPE HTML PUBLIC
[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
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
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
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
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 appears,
On Wed, 7 Jun 2000, Eric Cholet wrote:
This said, i hurry back to s/"constant strings"/'constant strings'/g;
Those two are equal.
--
Matt/
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy
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
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.
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 interrelated,
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 addition to
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
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 0
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: 10
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_print|111
.--[ 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, 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 one
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 . | _| |
\|| _.-~-._.-~-._.-~-._@"
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:
36 matches
Mail list logo
