• You mean you aren't checking the return of a sub before using what it returns?
• Why would you suppress the error system rather than the error?
• Could you change the sub so that it didn't return a non-numeric answer?
• Could you do as Mr. Fastolfe says and ensure the value of $x with the lovely my $x= subr() || 0;?
• Do you want programming in perl to be safe or sloppy?
• Testing for "definedness" isn't irrelevant in and of itself, do you really think that your testing of it was? Did "-w" think it was?

Ok I have to be declarative, I can't stand it. =) The flaw in your example is that you aren't controlling the issue in the correct place. If you wish to use some_sub() as numeric, make sure it returns a numeric value. Warnings are a contract with yourself, keep the contract at both ends. If you are explicitly ignoring a return (i.e. if the sub could return both 0 and undef) then don't get hung up on making that choice explict.

Also, while you are benchmarking, try the same test with warnings on and off and try turning the warnings on and off within the loop you test as well.

I'm willing to go out on a limb and bet the bit-flag test that defined() does is way cheaper than turning on and off warnings and _majorly_ cheaper than printing errors.

Perl is still doing the test for defined, it has to for greater than so it knows to promote $_ to 0 for the comparison. All you did is ask for the result of that test.

--
$you = new YOU;
honk() if $you->love(perl)

On the zero/undef/non-zero'edness of something, this is low overhead.

#!/usr/local/bin/perl -w

use strict;

{
   if (my $x = (maybe_undef_maybe_not () || 0))
   {
      print "Not Zero\n";
   }
   else
   {
      print "Zero\n";
   }
}

sub maybe_undef_maybe_not
{
   return undef;
}
[download]

Instead of a my var you should use use vars.

When I run your test having done that I get this:

Benchmark: running Do_not_test, Test_defined, each for at least 10 CPU
+ seconds...
Do_not_test: 10 wallclock secs (10.18 usr +  0.00 sys = 10.18 CPU) @ 7
+98.13/s (n=8125)
Test_defined: 10 wallclock secs (10.16 usr +  0.00 sys = 10.16 CPU) @ 
+671.75/s (n=6825)
[download]

my $x = some_func() || 0;
[download]

Actually it does look like the extra test for $_ affects execution speed.

Do_not_test: 11 wallclock secs (10.01 usr +  0.00 sys = 10.01 CPU) @ 365830.27/s (n=3661961)
Test_defined:  8 wallclock secs (10.02 usr +  0.00 sys = 10.02 CPU) @ 363485.63/s (n=3642126)

Ignoring the wallclock seconds, Do_not_test ran about 2,000 more times per second than did Test_defined (or about 0.5%). Okay, so it's not going to bring the CPU to a grinding halt, but every cycle counts (especially if, like me, you're still working on an old, old computer :)

Oh, and I think my $x = sub() || 0; is a good idea.

timethese(-70, {
  and => 'my $m=0; for(@nums){if ($_ and $_>2) {$m++}}',
  or => 'my $f=0; for(@nums){if (($_||0)>2) {$f++}}',
  def => 'my $n=0; for(@nums){if (defined $_ and $_>2) {$n++}}',
  base => 'my $q=0; for(@nums){if ($_>2) {$q++}}'
});

This produced:
Benchmark: running and, base, def, or, each for at least 45 CPU second
+s...
       and: 49 wallclock secs (47.71 usr +  0.05 sys = 47.76 CPU) @ 60
+77.60/s (n=290266)
      base: 44 wallclock secs (44.82 usr +  0.18 sys = 45.00 CPU) @ 62
+05.20/s (n=279234)
       def: 47 wallclock secs (44.96 usr +  0.04 sys = 45.00 CPU) @ 60
+34.82/s (n=271567)
        or: 45 wallclock secs (45.00 usr +  0.02 sys = 45.02 CPU) @ 60
+34.41/s (n=271669)
[download]

I'm all for optimization, when appropriate, but my corrolary to gnat's law is, "A program that executes completely -- but could be made to run slightly faster with slightly dodgier programming -- is faster than a program that falls over when it hits something you didn't plan for."

Depending on your design (specifically the abstraction and encapsulation), it may be appropriate to declare that your subroutine always returns numeric values. It may not. If there's a chance that the return value is undefined, I'd definitely do the check.

If that's the last optimization point in my program, I've done really, really well.

I have to agree with extremely here. You are testing downstream of where the problem really is.

When deciding questions like this, I like to focus on "What is the set of values that my function (expression, test, ... ) should accept?". After determining this, I write the function to handle those cases. I *want* to get warnings when values outside of my expected input set are given to my function. I even might code some calls to die() just to make sure I will notice when this happens.

In the example above, I would thus recommend to make sure some_sub() returns a value that makes sense to the rest of the program (e.g., only numeric values).

This line of reasoning may seem problematic if you think of generic routines, e.g., dispatching code that uses dynamic handler tables. It is not. If you assume anything about the functions you want to dispatch to, or get return values from, you better make that assumption public, either by encapsulating your assumptions in an interface (e.g., an abstract data type with operations to handle input arguments and return values), or by documenting your assumptions (not the real thing, but better than nothing).

Turning off "-w" in production code "so I don't see that pesky warnings stuff" (the other "solution" to your problem) makes me extremely nervous. Generally, if people argue like that, there will be problems. Tip: turning "-w" on in big applications that have it turned off often makes for interesting reading and hours of insight and fun.

Christian Lemburg
Brainbench MVP for Perl
http://www.brainbench.com

I'll echo several people and say that undef is not 0 and if there is no difference between the function returning 0 and it returning undef, then the function needs to be fixed to stop returning useless undefs. If there is a difference, then you need to not only tell Perl but tell whoever will next maintain your code that you consciously want to treat undef as if it were 0 because in this specific case that makes sense.

And trying to optimize 0.5% out of one tiny part of your code (so that your total CPU savings are more like 0.005%) at the cost of less clear code is madness.

But, I do feel your pain when it comes to dealing with undefined values without generating warnings. This is such a common problem that over and over again someone proposes an alternate form of ||, call it ||| this time, that works on undefinedness instead of falseness. That way you can write:

    my $x= some_sub() ||| 0;
[download]

    my $x= some_sub();
    $x |||= 0;
[download]

    my $x= def( some_sub(), -1 );
[download]

    my $x= some_sub();
    def( $x, -1 );
[download]