And foreach over (@array) doesn't build a new array, and foreach over (<FILEHANDLE>) doesn't slurp the whole file either. Not really a hack there. That is what foreach is for. Building a quick list to foreach over is cool, but throwing a huge list together in a hurry is hard, and worse, eats scads of memory.

The while loop is much better for large hashes like this case.

--
$you = new YOU;
honk() if $you->love(perl)

Only some of those are true.

It is true that foreach over (@array) uses the original array as a list. It is also true that foreach over (1..1_000_000) does not build a list of a million entries. But the file construct most assuredly does slurp a file. Try running the following command-lines interactively to show that:

perl -e '$| = 1; print while <>'
[download]

vs

perl -e '$| = 1; print foreach <>'
[download]

You will find that the first spits back your lines interactively. The second has to wait to slurp up everything you have to say before it starts printing.

Should you ever need to write a filter for dealing with a large amount of data, be very, very careful to use while instead of foreach!

But a random note. If you check the benchmark, you will find that keys ran faster, 423.73 iterations per second vs 356.01. If memory is not a constraint, then for hashes of this size, foreach is faster!

Ouch, I was aware of the fix that allows 1..1000000 to work, thus I started my post with "And...", I was, however under the impression that  foreach (<FH>) {} was special vs. foreach (<>) {}.

Guess I's been spoilt by dem fancy computairs wif all dat memoree. =) And I never tried to use $. before either, THAT would have made the problem clearer...

#!/usr/bin/perl -w

open FH, "</really/huge/file" or die "Eeek, $!\n";

foreach (<FH>) {
   print "$. - $_";
}
[download]

Ow! Every line has the same line number! =)

--
$you = new YOU;
honk() if $you->love(perl)

Doh! You're right of course, how silly not to notice it before - the break out test is completely stupid. (I guess in the back of my mind I must have thought the values were coming out in order - which of course they are not). It breaks out very early and that explains why it's so much faster.

If I change the test to >400000 (which gets me about 3/4 through the hash) then I get the following results...

Benchmark: timing 1000 iterations of each, keys...
      each:  2 wallclock secs ( 2.39 usr +  0.00 sys =  2.39 CPU) @ 418.41/s (n=1000)
      keys:  2 wallclock secs ( 2.23 usr +  0.00 sys =  2.23 CPU) @ 448.43/s (n=1000)
      Rate each keys
each 418/s   --  -7%
keys 448/s   7%   --

...so it looks like keys generally wins - because of the 'random' order that things come out, you can't tell how soon a loop test break you out of the loop.

Thanks tilly

rdw