[Haskell-cafe] Re: Lazy IO and closing of file handles

Donald Bruce Stewart dons at cse.unsw.edu.au
Wed Mar 14 19:15:43 EDT 2007


pete-expires-20070513:
> dons at cse.unsw.edu.au (Donald Bruce Stewart) writes:
> 
> > pete-expires-20070513:
> >> When using readFile to process a large number of files, I am exceeding
> >> the resource limits for the maximum number of open file descriptors on
> >> my system.  How can I enhance my program to deal with this situation
> >> without making significant changes?
> >
> > Read in data strictly, and there are two obvious ways to do that:
> >
> >     -- Via strings:
> >
> >     readFileStrict f = do
> >         s <- readFile f
> >         length s `seq` return s
> >
> >     -- Via ByteStrings
> >     readFileStrict  = Data.ByteString.readFile
> >     readFileStrictString  = liftM Data.ByteString.unpack Data.ByteString.readFile
> >
> > If you're reading more than say, 100k of data, I'd use strict
> > ByteStrings without hesitation. More than 10M, and I'd use lazy
> > bytestrings.
> 
> Correct me if I'm wrong, but isn't this exactly what I wanted to
> avoid?  Reading the entire file into memory?  In my previous email, I
> was trying to state that I wanted to lazily read the file because some
> of the files are quite large and there is no reason to read beyond the
> small set of headers.  If I read the entire file into memory, this
> design goal is no longer met.
> 
> Nevertheless, I was benchmarking with ByteStrings (both lazy and
> strict), and in both cases, the ByteString versions of readFile yield
> the same error regarding max open files.  Incidentally, the lazy
> bytestring version of my program was by far the fastest and used the
> least amount of memory, but it still crapped out regarding max open
> files. 
> 
> So I'm back to square one.  Any other ideas?

Hmm. Ok. So we need to have more hClose's happen somehow. Can you
process files one at a time?

-- Don


More information about the Haskell-Cafe mailing list