4 ms·

Assuming this is true (filters are faster than slurping) how do we explain the perception of Perl and the many similar interpreters that followed as being "fast

by gwu78 13y ago

Assuming this is true (filters are faster than slurping) how do we explain the perception of Perl and the many similar interpreters that followed as being "faster than the shell" (i.e. UNIX standard utilities and pipes). Since the dawn of Perl, and through the Python era, one could conclude that the shell and UNIX utilities have been all but abandoned for doing work with large files, in favor of using other interpreters and their myriad helper libraries. My guess is that hardware improved and made slurping easier to do. Available RAM increased as hardware improved. This allowed slurping to displace filters as the choice way to work with files. In a resource constrained environment, I still prefer filters to slurping. But how many developers or users today perceive their environment as resource constrained?

pnathan 13y ago
Actually, when I was using Perl a while ago (couple years now), `while(<$fh>) { ... }` was really the memory efficient way to do file work.
Terretta 13y ago
Except that Perl is filter mode. In Perl while (<FILE>) { print $_; } is line by line and efficient. Perl programmers avoid my @entire_file=<$yourhandle>; But even that loads the array line by line. As a side note, good Perl has always done things while there are things to do, in a list processing kind of approach feeling more functional than imperative. // Slurping the whole file into a single thing is actually a chore: http://stackoverflow.com/questions/206661/what-is-the-best-way-to-slurp-a-file-into-a-string-in-perl http://stackoverflow.com/questions/206661/what-is-the-best-w...
- mct 13y ago
  If you're writing a filter, an even better pattern is: while (<>) { ... } By omitting the file handle, "<>" will go line by line through each filename specified on the command line. If no filename arguments were passed, it reads from STDIN.
- shabble 13y ago
  I'm not sure if it's still the case (I recall some discussion about optimising it) but using the more obvious[1] idiom of foreach my $line (<$FH>) { ... } slurps the entire file because the foreach is forcing list context on the diamond operator. The while(<$FH>) { ... } that you describe works as desired though. http://stackoverflow.com/questions/585341/ http://stackoverflow.com/questions/585341/ appears to cover it in some detail. [1] To me, anyway.

by gwu78 13y ago

pnathan 13y ago

Actually, when I was using Perl a while ago (couple years now), `while(<$fh>) { ... }` was really the memory efficient way to do file work.

Terretta 13y ago

Except that Perl is filter mode. In Perl while (<FILE>) { print $_; } is line by line and efficient. Perl programmers avoid my @entire_file=<$yourhandle>; But even that loads the array line by line. As a side note, good Perl has always done things while there are things to do, in a list processing kind of approach feeling more functional than imperative. // Slurping the whole file into a single thing is actually a chore: http://stackoverflow.com/questions/206661/what-is-the-best-way-to-slurp-a-file-into-a-string-in-perl http://stackoverflow.com/questions/206661/what-is-the-best-w...

mct 13y ago
If you're writing a filter, an even better pattern is: while (<>) { ... } By omitting the file handle, "<>" will go line by line through each filename specified on the command line. If no filename arguments were passed, it reads from STDIN.
shabble 13y ago
I'm not sure if it's still the case (I recall some discussion about optimising it) but using the more obvious[1] idiom of foreach my $line (<$FH>) { ... } slurps the entire file because the foreach is forcing list context on the diamond operator. The while(<$FH>) { ... } that you describe works as desired though. http://stackoverflow.com/questions/585341/ http://stackoverflow.com/questions/585341/ appears to cover it in some detail. [1] To me, anyway.