HEAD: Deterioration in ByteString I/O

Daniel Fischer daniel.is.fischer at web.de
Thu Sep 9 10:08:28 EDT 2010


On Thursday 09 September 2010 13:19:23, Simon Marlow wrote:
> I think I've found the problem, GHC.IO.Handle.Text:
>
> bufReadNBEmpty :: Handle__ -> Buffer Word8 -> Ptr Word8 -> Int -> Int ->
> IO Int
> bufReadNBEmpty   h_ at Handle__{..}
>                   buf at Buffer{ bufRaw=raw, bufR=w, bufL=r, bufSize=sz }
>                   ptr so_far count
>    | count > sz, False,
>      Just fd <- cast haDevice = do
>         m <- RawIO.readNonBlocking (fd::FD) ptr count
>         case m of
>           Nothing -> return so_far
>           Just n  -> return (so_far + n)
>
>
> See if you can spot it.

Yes, that's it. Removing the literal False to make that branch reachable 
more or less reinstates old behaviour.

For I/O of (lazy) ByteStrings only, the allocation figures of HEAD are 
consistently slightly higher than those of 6.12.3, but the difference is 
less than 1%, well within the normal fluctuation due to changes in 
implementation. Timings seem to be identical.

When performing work on the ByteStrings (finding/replacing substrings), 
however, things change a bit.
The allocation figures observed so far range from almost identical (< 1% 
difference) to above 15% higher (90,146,508 bytes allocated vs. 
106,237,456), most of the differences I observed so far are between 5% and 
10%.
The wall clock time (elapsed, per +RTS -s or time) seems to be identical 
(very stable timings for multiple runs of the same benchmark), but the MUT 
times reported by +RTS -s differ for some benchmarks (between 10% less for 
HEAD and 20% more observed, but identical for most).

That might be worthy of examination, though it's not alarming.

Cheers,
Daniel



More information about the Glasgow-haskell-users mailing list