On 09/09/2010 15:08, Daniel Fischer wrote:
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.
If you can find an example that consistently allocates significantly more than with 6.12 (10%+), then I'd say it would be worth looking into. Cheers, Simon