Jay Savage wrote:
On Wed, Mar 26, 2008 at 9:47 PM, Rob Dixon <[EMAIL PROTECTED]> wrote:
Jay Savage wrote:
If you want to see grep really shine, though, think about ways you
might use it to avoid calling print for every element in the return
list, e.g.
print join "\n", grep {$_ % 2 == 0} @list;
I think that's very misleading. Why should I want to avoid calling print
for each element? What you've written is the sort of thing for which
Perl gets a bad name - it's less readable and has no obvious benefits
over
print "$_\n" foreach grep { $_ % 2 == 0 } @list;
cmpthese(1000, {
'foreach' => sub { print "$_\n" for grep {$_ % 2 == 0} 0..1000; },
'join' => sub { print join "\n", grep {$_ % 2 == 0} 0..1000; },
});
Rate foreach join
foreach 40.7/s -- -20%
join 50.8/s 25% --
25% performance gain strikes me as a pretty obvious benefit. YMMV, of
course, depending on your data and memory performance, but in general,
function calls are expensive, and and print moreso than most, because
it requires a system call out to the OS. Calling a function like print
on each iteration through a loop is rarely the most efficient way to
do business.
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.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. In any
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'.
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.
This doesn't really have anything to do with Perl; it's true in any
language.
Yes, but now you mention it I would be surprised to see this technique
used in C:
char buff[10000] = "\0";
int n;
char convert[10];
for (n = 0; n <= 1000; n++)
{
sprintf(convert, "%d\n", n);
strcat(buff, convert);
}
fputs(buff, stdout);
But perhaps I am wrong.
Of course, efficiency, like beauty, is in the eye of the beholder. And
that's why I was clear with OP, that he should do whatever made the
most sense for him in his particular situation.
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.
(It also doesn't print a terminating "\n")
I think you'll agree there are several trivial fixes for this. 'print
"\n"' jumps immediately to mind.
Yes, of course. I was simply pointing out that they weren't equivalent.
Cheers,
Rob
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/
