On 05/21/2012 03:12 PM, sono...@fannullone.us wrote:
Hi Paul,
Please don't care about this until your code is running correctly but
too slowly and profiling has determined that this is the bottleneck.
I'm curious as to why you say this. If one way is faster than another,
wouldn't it be better to do it that way, as long as it doesn't cause any
problems?
BTW, my code is running correctly. I'm refactoring an old script. The
way I see it, every little bit helps. =;)
Marc
For one thing, there is the "Lies, Damned Lies and Benchmarks" factor.
All that has been shown is that at some point in time, with some version
of Perl, on some machine, under some conditions, one method was faster
than the other by some small percentage. Whenever you have a set of
benchmarks that are close to each other, things that are not measured by
the benchmark can truly swamp the numbers. Factors like stack
alignment, cache line size or system paging can make the first last and
the last first.
For a second thing: Unless the ONLY thing your subroutine does is pull
its arguments from the stack, the gains of using one technique versus
another will be down in the noise compared to your actual *code*. If
you are writing some piece of trivial code that gets called many, many,
many times (say - a class accessor) then using the fastest (which, as
you'll recall from the message upthread was neither shift nor assign,
but using @_ directly) would make sense.
For the third thing: Every little bit does *not* help. As Paul
mentioned - ONLY when performance becomes an issue should you start
thinking about optimization ("Premature Optimization is the root of all
evil") -- pick a method that makes sense to you and use it consistently.
My personal bias is: Since I write 99% OO code, the very first thing I
do is "my $self = shift;" As to the rest of the arguments, sometimes I
pull them into lexicals, sometimes I leave them in @_ to shift them off,
*depending on which makes the easiest code to read*. Less than a dozen
times in twenty years has the value of the computers' time been within
orders of magnitude of the value of the humans time who manage the
computer.
To summarize: Dogmatically using one technique over another because,
"it's faster" in this case is...
a) Not true. Benchmarks can and do lie.
b) Not important. The actual WORK your code does should be much
more of the time than the mechanism for getting your arguments
c) Not good for you. Code that you (and your successors) can
maintain is far more valuable than code that might be faster.
--L
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
