Aaron Sherman writes:
> On Mon, 2005-04-25 at 22:24 -0500, Rod Adams wrote:
>
> > Not exactly a fair comparison, since it's common to not "use English"
> > due to the $& issue.
> >
> > I suspect that if that was not the case, it would be used more.
>
> The reasons I don't "use English" in P5:
>
> * Variable access is slower
% perl -MBenchmark=timethese -MEnglish -e 'timethese(1e6, {
"/" => sub { $/ = "\n" },
"RS" => sub { $INPUT_RECORD_SEPARATOR = "\n" }
})''
Benchmark: timing 1000000 iterations of /, RS...
/: 2 wallclock secs ( 1.41 usr + 0.00 sys = 1.41 CPU) @ 709219.86/s
(n=1000000)
RS: 1 wallclock secs ( 1.20 usr + 0.05 sys = 1.25 CPU) @ 800000.00/s
(n=1000000)
Hmm, looks to me like $INPUT_RECORD_SEPARATOR is faster. (Actually
they're the same: on each run a different one won, but just barely like
this).
When will you people stop caring about speed that doesn't matter. Even
if $/ were faster, it would only be by a neglegable amount. Your
readability is a lot more important than a few clock cycles here and
there.
Ever since I stopped caring about speed, I've started to write code
almost twice as fast. And the code itself isn't slower. It's just the
fact that after I used to write every line, I would think "is this fast
enough; could I make it faster?". I would even trip myself up,
abandoning projects because I couldn't find a fast enough way to do it,
or because my current implementation was too slow. But not by evidence,
just by judgement upon looking at the code.
Speed is important. And I'm a game programmer, so speed is pretty
important to me. I've found (and this is widely known, but perhaps
every programmer needs to discover it for himself) that it is hard to
tell where you will be spending most of your cycles. Once you know,
then you can go back and optimize it.
And I promise, that will never be somewhere where the difference between
$/ and $INPUT_RECORD_SEPARATOR matters.
Luke
