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_@Handle__{..} buf@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