Joe Schaefer wrote:
Stas Bekman <[EMAIL PROTECTED]> writes:

[...]


Two questions:

1) did you by chance look at how this magic is generated?


I'm not sure exactly how it all works; probably some combination
of overload.pm and internal support from perl itself.  I think
all the fallback option actually does is set

    ${"APR::Error::()"} = 1


Do we pay any penalty for letting overload handle that?


IMO the costs are comparable to everything else related to
using overload, so I don't expect it to be too costly.
I could be wrong though, so benchmark that if it's a concern.

The 'fallback' approach is almost 3 times slower:

Benchmark:
timing 1000000 iterations of
 explicit, fallback
...

explicit: 6 wallclock secs ( 4.17 usr + 0.05 sys = 4.22 CPU) @ 236966.82/s (n=1000000)

fallback: 14 wallclock secs (11.22 usr + 0.10 sys = 11.32 CPU) @ 88339.22/s (n=1000000)


here is the benchmark:

use strict;
use warnings;

package A;

use overload
     fallback => 1,
     '0+'     => sub { $_[0]->[0] };

sub new { bless [5], __PACKAGE__ };

package B;

use overload
     '=='    => sub { $_[0]->[0] == $_[1] },
     '0+'    => sub { $_[0]->[0] };

sub new { bless [5], __PACKAGE__ }

package main;

use Benchmark qw(timethese) ;

my $a = A->new;
my $b = B->new;

timethese(1_000_000,
          {
           'fallback' => sub { $a == 5 ? "OK" : "NOK"},
           'explicit' => sub { $b == 5 ? "OK" : "NOK"},
          });

2) is it safe to rely on the magic for other ops we haven't thought
of?

I think so. If not, I'd say that's a bug in overload.pm itself.

Well, I just reported a segfault caused by overload (well it can be easily avoided, was caused by a recursive overload).


How about we keep an explicit mapping for now and add fallback if later we will see that there is a need for it?

--
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to