On Thu, Mar 27, 2008 at 2:22 PM, Rob Dixon wrote:
Yes I understood your intention, but efficiency isn't everything by any
means. I believe very firmly that programs should be coded in the
clearest and most obvious way possible, then tested and optimised if the
performance is inadequate.
In general, I agree with you; but I maintain that "clear" and
"obvious" are subject to interpretation. I also maintain that using
grep to feed input to a for loop isn't obvious, whereas using grep to
optimize out a loop is. There is nothing that grep does that can't be
done in a loop, and we normally use grep when, for whatever reason, we
want to avoid a loop.
The most natural way to print a list of data
is simply to print each item, and to code it differently from that is to
start on the road of efficiency at the cost of intelligibility.
Again, I don't entirely disagree. But this thread isn't about the most
natural way to print lists. It's about grep.
case, if someone offered me a way of making my program run in 20ms
instead of 25ms I wouldn't be overly impressed, and certainly don't see
it as a case of grep 'shining'.
I think you missed my point. I may not have been clear. No, shaving a
few ms off runtime isn't shining. But it's an *example* of the *type*
of thing grep shines at. That is, taking loops and tunring them into
blocks, and cutting out, in this case, 999 system calls. Are the
savings anything to write home about? No, of course not. But the
*idea* is fantastic, and in a more complicated situation often leads
to not just faster execution, but saved programmer time, increased
clarity, and simplified control structures.
Again, it's not about a few prints in this particular made-up case.
It's about the types of things grep really does well.
My guess is that optimising out print calls would be less, not more
effective than with most subroutines: all it does is to append the
passed-in data to the output buffer, and the system call is performed
only when that buffer is filled.
Well, that depends entirely on what file handle you're printing to. If
you're printing to STDOUT, as all these examples so far have, each
newline--and therefore each pass though the loop that matches the
condition--flushes the buffer.
This doesn't really have anything to do with Perl; it's true in any
Yes, but now you mention it I would be surprised to see this technique
used in C:
That's because C doesn't have grep. The extra variable assignments and
sprintfs you need to make the "equivalent" C code eat up any potential
gains. The situation of he two languages isn't at all comparable.
TIMTOWTDI isn't what gives Perl a bad name; it's what makes it the
wonderful, flexible tool that it is, and crates passionate groups of
users like this one.
My concern is that Perl has a reputation for appearing to be an
unintelligible string of symbols, and I am wary of anything that even
leans in that direction.
Point well taken. But this is a thread about grep; and grep's raison
d'etre is optimizing out loops. I don't think giving an example that
shows grep cutting a loop is out of order. I certainly hope it wasn't
It's also the little optimizations (like grep and map) that are built
into the language that set Perl apart from the crowd.
This email and attachment(s): [ ] blogable; [ x ] ask first; [ ]
private and confidential
daggerquill [at] gmail [dot] comhttp://www.tuaw.com http://www.downloadsquad.com http://www.engatiki.org
values of β will give rise to dom!