>>>>> "CW" == Conor Walsh <[email protected]> writes:
CW> On 2/4/2011 3:37 PM, Uri Guttman wrote:
>> now, depending on how large the file is, slurping it may be faster than
>> reading it line by line (larger files will win more). the reason is
>> perl's stream i/o is slower than a single slurp.
CW> Slurping is fun, but only works if you can fit the file in memory.
CW> The moment you run into a too-large file, that approach fails hard.
CW> On the other hand, I've gotten excellent performance out of while()
CW> {sysread(); process();} on multi-GB files, so I'm definitely with you
CW> on the slowdown in <FH> calls.
agreed. i never advocate slurping for GB files as thrashing will kill
you. but what is annoying is that most text files today are almost
always slurpable and line by line is still used everywhere. when ram
size was super small line by line was the only way to go. a 1 MB text
file would swamp machines back then. today it is less than 1% of a
common box's ram of 1GB. we have to change our perception of what small
and large is to get the most out of our boxes. my fave version of this
idea is slurping and parsing a simple config file in one line. faster
than any other way to do it and shorter as well. this is a file of lines
with key=value.
use File::Slurp ;
my %config = read_file( $file ) =~ /^(\w+)=(.+)$/mg ;
years ago when i would need to parse a block of text with start/end
markers i would use the .. range operator to detect when they started
and ended. now i slurp in the file and use a global regex to grab each
section and call a process sub with the grabbed part. much simpler and
much faster. slurping is a much better way to process a normal sized
text file in almost all cases.
uri
--
Uri Guttman ------ [email protected] -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
_______________________________________________
Boston-pm mailing list
[email protected]
http://mail.pm.org/mailman/listinfo/boston-pm
