SamQi has asked for the wisdom of the Perl Monks concerning the following question:

In some of my recent code I've been using the trinary operator a lot. I suspect it may be slightly faster since it doesn't involve opening code blocks and is an operator instead of a keyword (this may be a load of bulshit, mind you)...

So....I figure I'll benchmark it. Great...I can't seem to devise good test cases.

This brings me to call upon the wisdom of my fellow Monks. First off, can somebody help me figure out some good test cases. Maybe even give me some generic guidelines for creating test cases to use with Benchmark.pm. And....if anybody happens to know off the top of their head the speed differences between the two, that'd be helpful too. ::smile::

I understand that the trinary obfuscates the code a degree...but if it gains a speed boost, I can comment it to hell and back. The thought just occured to me...does the optimizer change an If'n'Else into a trinary anyway?

Replies are listed 'Best First'.
Re: Trinary or If'n'Else?
by chromatic (Archbishop) on Dec 22, 2000 at 06:11 UTC
    Run perl -MO=Deparse on your code to see what it looks like after optimization. On Perl 5.5.3 on my box, it doesn't change it.

    As for a benchmark, here's what I used:

    sub trinary { my $a = 1; my $b = 0; return $a > $b ? $a : $b; } sub if_else { my $a = 1; my $b = 0; if ($a > $b) { return $a; } else { return $b; } } use Benchmark; timethese(500000, { trinary => \&trinary, if_else => \&if_else, });
    You can play with different ways of constructing the if-else block. With 500,000 iterations, the ternary is 4% faster. I wouldn't worry about a difference like that.

    Removing the else flips it the other way:

    sub if_else { my $a = 1; my $b = 0; return $a if $a > $b; return $b; }
Re: Trinary or If'n'Else?
by Maclir (Curate) on Dec 22, 2000 at 06:41 UTC
    Chromatic has already commented on the (lack of) performance differences.

    Obfuscation is in the eye of the observer (obfuscatee?), however. For someone who many years ago programmed in apl, so what? I believe that used appropriately, the trinary operation can be much clearer. For example, consider the following:

    $some_variable = (defined $parm1) ? $parm1 : $default;
    compared to:
    if (defined $parm1) { $some_variable = $parm1; } else { $some_variable = $default; }
    and imagined it is duplicated 10 or 20 times. If you understand the perl syntax, there is no obfuscation.
Re: Trinary or If'n'Else?
by Fastolfe (Vicar) on Dec 22, 2000 at 08:26 UTC
    I wouldn't worry at all about performance between the two. Just use what makes sense in your code. Don't do stuff like this:
    $some_condition ? &some_sub : &other_sub; if ($some_condition) { $some_var = &something; } else { $some_var = $something_else; }
    Use the operators for what they were designed, and your code will be infinitely more readable and usable.
Re: Trinary or If'n'Else?
by Anonymous Monk on Dec 22, 2000 at 08:46 UTC
    On a related note, could anyone explain the difference between:
    a ? b : c
    a && b || c
    (besides the fact that the hook operator can be assigned to).
      The main thing about the trinary operator is that, quoting your case above, "a" is a logical expression; where as b and c may be any expressions that return a result compatible with what you are assigning the expression to (or the other way around, if you are assinging to the operator). While most of the examples mentioned are just simeple assignments ($fred = (some_condition)? $bar : $foo), the statement is much more powerful than that.
        I'm not sure I understand. As far as I can see, ?: and &&|| do the same thing:
        print 1 ? 'true' : 'false'; # True print 1 && 'true' || 'false'; # True print 0 ? 'true' : 'false'; # False print 0 && 'true' || 'false'; # False
        In both a ? b : c and a && b || c, a is a boolean expression. What can ?: do that &&|| cannot?
Re: Trinary or If'n'Else?
by nop (Hermit) on Dec 22, 2000 at 18:49 UTC
    To make your code faster, closely examine your algorithm and logic. Profile where your code is spending its time.

    Improvements here can are thousand-fold more important than the minor speed issues of ? vs. if-then-else.

    My two cents.

    nop
Re: Trinary or If'n'Else?
by SamQi (Beadle) on Dec 24, 2000 at 00:23 UTC

    Thanks for the helpful responses, guys. I'll keep this information in mind when I go and do another revision to the code.