At 11:27 AM +0800 3/20/01, Stas Bekman wrote:
>On Mon, 19 Mar 2001, Paul wrote:
>
>>
>> --- Geoffrey Young <[EMAIL PROTECTED]> wrote:
>> > mod_perl digest
>> > March 11, 2001 - March 17, 2001
>> > Recent happenings in the mod_perl world...
>> > . . .
>> > mailing list highlights
>> > . . .
>> > o There was an OT but interesting thread on whether lexical
>> > variables are faster than global variables [10]. This
>> > response in particular may be of interest to those who
>> > want to know more about perlguts [11]
>>
>> As one more installment on that thread, I got an email using Benchmark
>> to test it. It had the my() inside the test function, which was slower
>> than package globals, but I moved it out and it was faster.
>>
>> Here's the test synopsis:
>> ===========================
>> C:\users\default>type tmp.pl
> > use Benchmark;
>> my $o; # packagewide deep-bound my() var
>> sub outMY{
>> $o = 0; # packagewide deep-bound my() var
>> $o++ while ($o < 1000);
>> };
>> sub inMY{
>> my $i = 0; # function-internal my() var
>> $i++ while ($i < 1000);
>> };
>> sub gPK{
>> $g = 0; # package global var
>> $g++ while ($g < 1000);
>> };
>> timethese(5000, { 'External' => \&outMY,
>> 'Internal' => \&inMY,
> > 'Global' => \&gPK } );
>>
>> C:\users\default>perl -w tmp.pl
>> Benchmark: timing 5000 iterations of External, Global, Internal...
>> External: 5 wallclock secs ( 4.96 usr + 0.00 sys = 4.96 CPU)
>> Global: 5 wallclock secs ( 5.01 usr + 0.00 sys = 5.01 CPU)
>> Internal: 4 wallclock secs ( 5.07 usr + 0.00 sys = 5.07 CPU)
>>
>> ===================================================================
>> Notice that a deep-bound my() variable was fastest, while a re-scoped
>> my() was slowest, the package global being pretty close to halfway
>> between in actual CPU usage.
>>
>> Hope that's useful to somebody. =o)
>
>Unfortunately it's not very useful when the results are so close, unless
>you specify the platform, compiler args, which malloc version was used and
>much more. And others use the same or a similar setup.
>
>I've run the same benchmark on linux(k2.2.17), perl 5.6.1-PATCH2 and there
>are all the other details that I'm not telling here. But just to make a
>point, I get results with 'global' always being faster and
>external/internal giving relatively inconsistent results (see the
>variations on CPU cycles). For example, your code executed four times:
>
>[snip]
Normally, a stash in the average program contains hundreds of entries
from different packages. That must have some impact on the speed of
the globals, right?
Well... I tested it (sort of) and created 1000 fake subs to populate
the stash with extra entries.
for my $i (1..1000) {
*{"x$i"} = sub {
print $i."\n";
};
}
Then continued to run the code above with the following results
Benchmark: timing 5000 iterations of External, Global, Internal...
External: 3 wallclock secs ( 3.07 usr + 0.01 sys = 3.08 CPU) @
Global: 3 wallclock secs ( 3.07 usr + 0.00 sys = 3.07 CPU) @
Internal: 4 wallclock secs ( 3.10 usr + 0.00 sys = 3.10 CPU) @
Benchmark: timing 5000 iterations of External, Global, Internal...
External: 9 wallclock secs ( 3.25 usr + 0.00 sys = 3.25 CPU) @
Global: 6 wallclock secs ( 3.08 usr + 0.01 sys = 3.09 CPU) @
Internal: 3 wallclock secs ( 3.10 usr + 0.00 sys = 3.10 CPU) @
Again, the globals were fastest, even with 1000 extra sybols in the stash.
And then I thought that perhaps the stash was ordered alphanumercally
to improve performance. So I renamed my 1000 subs with a "d$i"
instead of the "x$i" and ran the test again, but I came up with the
exact same numbers...
Then, I tried upping the number of symbols... first to 10000 then to
100000 and ran again with the EXACT same times.
What can we conclude from all of this? That Lexicals and globals run
at (roughly) the same speed, and that tmtowtdi...
Rob
--
Warning: The contents of this message are made of bits which may or may not
be an accurate representation of my thoughts.
