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