Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris

Re^3: Matching in huge files

by Anonymous Monk
on Jul 06, 2006 at 16:14 UTC ( #559615=note: print w/replies, xml ) Need Help??

in reply to Re^2: Matching in huge files
in thread Matching in huge files

Yep, it is very fast, but why is that better than this:
open(F, "<", $file) or die "$file: $!"; binmode(F); undef $/; # switch off end-of-line separating # read file in large chunks while (<F>) { while ( m/$re/oigsm ) { print "$1\n"; } } $/ = '\n'; # switch back to line mode close(F);



Replies are listed 'Best First'.
Re^4: Matching in huge files
by dws (Chancellor) on Jul 07, 2006 at 00:16 UTC

    but why is that better than this: ...

    My fragment doesn't assume that the huge file will fit in memory, and it matches across read boundaries. Your approach sets up for a single-read slurp.

Re^4: Matching in huge files
by JadeNB (Chaplain) on Sep 05, 2008 at 18:25 UTC
    In addition to the answer that dws has already given, the original approach is better because it doesn't assume that the IRS was previously "\n", and it certainly doesn't put the IRS back as a literal \n (not a newline character, because of the single quotes). The usual idiom for changing $/ is to wrap any changes to it in a block, and then localise within the block.

    Also, maybe it's just my unfamiliarity with binmode, but I think that undef-ing the IRS means that the while loop only ever runs once.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://559615]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (3)
As of 2022-06-26 17:11 GMT
Find Nodes?
    Voting Booth?
    My most frequent journeys are powered by:

    Results (86 votes). Check out past polls.