Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • I assume it's to avoid calling the method on undef values.

    So try to find (or establish) the boundary where $var is always known to not be undef. Test it once there, and not in an inner loop. If possible, it may very well not be.

    If that's not feasible, how about introducing null objects instead of undef values?

    Re: squeezing out performance. Do you need the overhead of calling blessed? If $var contains a string instead of an object, $var->isa is going to work as a class method anyway, right? (and return fa
    • At the present time, the possible values of $var are strings, arrayrefs, hashrefs and regular expressions. That's why the blessed call is in there. However, there is one naughty trick I can do. The class I'm actually testing for creates logic variables. Since I control that class, if I declare that class as final and since I don't override isa, I can use UNIVERSAL::isa() as a function call:

      Benchmark: timing 200000 iterations of blessed, eval, universal...
         blessed:  1 wallclock secs (

      • If you were really evil, you could avoid the sub call, stringify the possibly-a-ref, and check the first n characters against the name of your class.

        • Benchmark: timing 200000 iterations of blessed, eval, stringify, universal, unpack...
             blessed:  1 wallclock secs ( 0.85 usr +  0.00 sys =  0.85 CPU) @ 235294.12/s (n=200000)
                eval:  2 wallclock secs ( 1.71 usr +  0.00 sys =  1.71 CPU) @ 116959.06/s (n=200000)
          stringify:  1 wallclock secs ( 1.08 usr +  0.01 sys =  1.09 CPU) @ 183486.24/s (n=200000)
          universal:  1 wallclock secs ( 0.60 usr +  0.00 sys =  0.60 CPU) @ 333333.33/s (n=200000)
              unpack:  2 wallclock secs ( 1.35 usr +  0.00 sys =  1.35 CPU) @ 148148.15/s (n=200000)

          I also expect nastiness with Pointer [] could be thrown into the mix.