Re^8: The Most Essential Perl Development Tools Today (implicit return)

[topher]

Please note, I'm not saying that you should always use a return statement. I'm not even saying that you should usually use an explicit return statement.

I have absolutely no problem with omitting it in any and all cases where it makes sense. I just don't think that the negligible performance difference is a good justification for not using it. Coding style, clarity, and lack of need are all good reasons to omit it; performance isn't.

[Anonymous Monk]

Coding style, clarity, and lack of need are all good reasons to omit it; performance isn't.

Sure it is.Performance is just as good a reason to adopt a certain style , heck, its even a better reason.

Explicit return adds less than 1% clarity in 99% of situations; while implicit returns outperforms it 98% of the time.

$ perl -MBenchmark=:all -e " cmpthese -3, { a=>sub{return int @_}, b=>
+sub{int@_},c=>sub{scalar@_},d=>sub{0+@_}} "
        Rate    a    d    b    c
a  5279994/s   -- -35% -52% -67%
d  8131795/s  54%   -- -26% -50%
b 10997789/s 108%  35%   -- -32%
c 16189364/s 207%  99%  47%   --

[tye]

Look Lisa, I found numbers on the Internet from a computer. They must be true. I win.   --Homer

 $ perl -MBenchmark=cmpthese -e'cmpthese( 2e6, {
ri=>sub{return int @_},
rs=>sub{return scalar @_},
rz=>sub{return 0+@_},
i=>sub{int@_},
s=>sub{scalar@_},
z=>sub{0+@_}})'
            (warning: too few iterations for a reliable count)
            (warning: too few iterations for a reliable count)
            (warning: too few iterations for a reliable count)
            (warning: too few iterations for a reliable count)
            (warning: too few iterations for a reliable count)
            (warning: too few iterations for a reliable count)
         Rate   rz   ri    z   rs    i    s
rz 14285714/s   -- -21% -21% -43% -43% -57%
ri 18181818/s  27%   --  -0% -27% -27% -45%
z  18181818/s  27%   0%   -- -27% -27% -45%
rs 25000000/s  75%  37%  37%   --   0% -25%
i  25000000/s  75%  37%  37%   0%   -- -25%
s  33333333/s 133%  83%  83%  33%  33%   --

The warnings are there to tell you that Benchmark tried to "eliminate overhead" for you but doing so showed that the run times were so short as to not matter. The differences, doubly so.

If you modify Benchmark to stop inflating the differences via subtracting minimal overhead, you get a somewhat more realistic picture:

        Rate   rz   ri    z   rs    i    s
rz 3076923/s   --  -5% *-6%* -9% -11% -15%
ri 3225806/s   5%   --  -2%  -5% *-6%*-11%
z  3278689/s  *7%*  2%   --  -3%  -5% -10%
rs 3389831/s  10%   5%   3%   --  -2% *-7%*
i  3448276/s  12%  *7%*  5%   2%   --  -5%
s  3636364/s  18%  13%  11%  *7%*  5%   --

So, if you have subroutines that do nothing but trivially look up the 0 stored in the size field of the @_ array, then you can make those trivial subroutines run about 5% faster when you actually have to worry about bothering to call them (doing nothing at all other than calling them over and over again 2e6 times -- in the most efficient way the authors of Benchmark.pm could figure out, ways that just throw away any useful work from the subroutines).

If you pretend that you can even do the impossible and you have a useful script despite it doing almost nothing at all else besides calling those trivial subroutines as efficiently as possible... then you can reduce your run-time from 5 seconds to 4.75 seconds. And nobody will notice.

In the real world, the difference would be even tinier and nobody could notice even if they tried very hard to.

You might as well make your style decisions based on what colors you see when you press your fingers into your closed eyes as on this "speed-up".

s/your press/you press/ done after it was quoted below.

[Anonymous Monk]

You might as well make your style decisions based on what colors you see when your press your fingers into your closed eyes as on this "speed-up".

:)

[Anonymous Monk]

The warnings are there to tell you that Benchmark tried to "eliminate overhead" for you but doing so showed that the run times were so short as to not matter. The differences, doubly so.

-3 is not the same as 2e6

On my machine 2e6 is way too slow