Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

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

by Anonymous Monk
on Jan 08, 2013 at 08:20 UTC ( [id://1012187]=note: print w/replies, xml ) Need Help??


in reply to Re^6: The Most Essential Perl Development Tools Today
in thread The Most Essential Perl Development Tools Today

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

Replies are listed 'Best First'.
Re^8: The Most Essential Perl Development Tools Today (implicit return)
by topher (Scribe) on Jan 08, 2013 at 19:40 UTC

    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.

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

        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".

        - tye        

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

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1012187]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others browsing the Monastery: (6)
As of 2024-03-19 02:35 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found