in reply to Re: Unfortunately benchmarking things with $& isn't easy...
in thread Obtaining server name from UNC path

That's stupid. ...

Hmm, perhaps. The way I was looking at it is that its a * k / b * k (which im not arguing is correct, as i dont know, merely explaining :-). Where if the k=1 when using eval and k=1.1 using a subref the ratio stays the same. Maybe this isnt the correct analysis, if so please enlighten me, but please without the "stupid" bit, im well well aware of my own limitations. :-)

If the ratios of two algorithms would vary wildly from machine to machine...

I have to admit that I assumed you meant the rate per second. Now that I see what you mean I concede my point is not correct.

Right figure, wrong conclusion. The slowdown isn't mainly caused by the use of $&, but the copying involved.

Wow. You are sooo right. If you look closely at my redo of theorbtwos code and the code in bm_theorbtwo.pl the assignment that is present is responsible for the difference. When I made sure that the combined version and the seperate version were _exactly_ the same the results were comparable. Thanks. And good point.

the costs of $& and more so from $` and $' come if you are using other regural expression in your program, for which you don't use $& and friends. But that's not what you are benchmarking.

Actually that was what I was trying to get at, if in a somewhat oblique way. :-). Anyway, it looks to me that the presence of $& doesnt in the end have much effect on the validity of the benchmark. Which is cool and interesting. Thanks Abigail-II.

BTW, i assume 

my $opts='-5 \\\\\\\\foo\\\\bar\\\\baz.exe';

[download]
is because your shell is converting \\ to \?

Yves / DeMerphq
---
Software Engineering is Programming when you can't. -- E. W. Dijkstra (RIP)

Replies are listed 'Best First'.
Re: Unfortunately benchmarking things with $& isn't easy...
by Abigail-II (Bishop) on Aug 08, 2002 at 16:04 UTC
    Hmm, perhaps. The way I was looking at it is that its a * k / b * k (which im not arguing is correct, as i dont know, merely explaining :-). Where if the k=1 when using eval and k=1.1 using a subref the ratio stays the same.
    But the cost of calling a sub is independent of the size, or running time, of the body of the sub. Hence, you get (fixed) additional time for each of the clauses that contain a sub ref. And you pay that price *for each invocation of the sub*. When using a string, the code is evalled only once.

    Here's a benchmark of a fairly trivial action, once done with a sub, and once done with an eval: 

    use strict;
use warnings 'all';
 
use Benchmark 'cmpthese';

$::a = "foo-bar";
cmpthese -5 => {
    sub  =>  sub {$::a =~ /([-])/},
    str  =>      '$::a =~ /([-])/',
};
__END__
Benchmark: running str, sub for at least 5 CPU seconds...
       str:  5 wallclock secs ( 5.34 usr +  0.00 sys =  5.34 CPU) @ 39
+0154.68/s (n=2083426)
       sub:  5 wallclock secs ( 5.13 usr +  0.00 sys =  5.13 CPU) @ 28
+2139.18/s (n=1447374)
        Rate  sub  str
sub 282139/s   -- -28%
str 390155/s  38%   --

    [download]
    Here's the relevant code from Benchmark::runloop: 
        my ($subcode, $subref);
    if (ref $c eq 'CODE') {
        $subcode = "sub { for (1 .. $n) { local \$_; package $pack; &\
+$c; } }";
        $subref  = eval $subcode;
    }
    else {
        $subcode = "sub { for (1 .. $n) { local \$_; package $pack; $c
+;} }";
        $subref  = _doeval($subcode);
    }

    [download]
    BTW, i assume 
    my $opts='-5 \\\\\\\\foo\\\\bar\\\\baz.exe';

    [download]
    is because your shell is converting \\ to \?
    Yes. I could have used 
    my $opts=q!-5 '\\\\foo\\bar\\baz.exe'!;

    [download]
    too.

    Abigail

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom