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__{..}
> b...@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
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
