Re^6: The Most Essential Perl Development Tools Today

[topher]

Did you forget an explicit return? Forget? No. Omit? Quite likely. Live with it. Cos nothing in this world is going to make me give up a 400% speed gain:

[0] Perl> sub a(){ 1 }; sub b(){ return 1; };; [0] Perl> cmpthese -1,{
+ a=>q[ a() for 1 .. 1000;], b=>q[b() for 1 .. 1 +000;] };; Rate b a b
+ 4668/s -- -80% a 23195/s 397% --
[download]

Just in case some (Perl) newbie doesn't get that subroutines return the value of their last expression and need a keyword to tell them so. No way José.

Your benchmark is rather bogus. The performance "hit" from the return statement is negligible. It's the prototype for no arguments with no return statement that gives a seeming big return (I'm guessing the interpreter is optimizing it to nearly a no-op).

$ perl -E 'use Benchmark qw(timethese cmpthese); sub a() { 1 }; sub b(
+) { return 1 }; cmpthese -1,{ a=>q[ a() for 1 .. 1000;], b=>q[b() for
+ 1 .. 1000;] };'
     Rate    b    a
b  2694/s   -- -88%
a 23209/s 761%   --
$ perl -E 'use Benchmark qw(timethese cmpthese); sub a { 1 }; sub b { 
+return 1 }; cmpthese -1,{ a=>q[ a() for 1 .. 1000;], b=>q[b() for 1 .
+. 1000;] };'
    Rate   b   a
b 2595/s  -- -8%
a 2823/s  9%  --

Is there a performance gain from not using return in this spot? Yes.

Is it a premature micro-optimization which is unlikely to have anything but a negligible impact the vast majority of real world code? Yes.

Would I consider this performance gain an invalid reason to skip a return statement on any code that hasn't been profiled and clearly shown to benefit from this micro-optimization? Yes.

[BrowserUk]

to skip a return statement

Would I consider the flagrant waste of even 10% of cycles through the addition of a redundant and purposeless extra keyword, an affectation who's time has past. Emphatically so!.

[topher]

As mentioned in another comment, I don't have a problem with omitting a return statement when it makes sense. I just don't think that performance is a good reason to do so.

[Anonymous Monk]

Is it a premature micro-optimization which is unlikely to have anything but a negligible impact the vast majority of real world code? Yes.

No, its called style :)

map, grep, sort, s{}{...}e don't allow you to use return, they force you to use implicit return

explicit return isn't required in do/eval/sub

return tells you about this

so unless you're coding something recursive, something that requires short circuiting, most perlish perl programmers omit the explicit return, and use the implicit return

If explicit return costs more (I'll take BrowserUk's word that it does), its a problem with the implementation, something for p5p to fix, same as they did for map in void context

[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%   --