HEAD: Deterioration in ByteString I/O

[Simon Marlow]

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_ 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.

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