HEAD: Deterioration in ByteString I/O

Don Stewart dons at galois.com
Wed Sep 8 12:10:26 EDT 2010


daniel.is.fischer:
> Trying out HEAD (specifically, ghc-6.13.20100831-src.tar.bz2 built with 
> 6.12.3) investigating an issue with the text package, I found that I/O of 
> ByteStrings has become significantly slower (on my machine at least:
> 
> $ uname -a
> Linux linux-mkk1 2.6.27.48-0.2-pae #1 SMP 2010-07-29 20:06:52 +0200 i686 
> i686 i386 GNU/Linux
> 
> Pentium 4, 3.06GHz).
> 
> Timings for reading and outputting a 74.3MB file:
> 
> cat:
> $ time cat bigfile > /dev/null
> 0.00user 0.04system 0:00.06elapsed 83%CPU
> 
> ghc-6.12.3:
> $ time ./nbench lazyBSNull bigfile a b > /dev/null
> 0.01user 0.09system 0:00.10elapsed 100%CPU
> 
> ghc-6.13.20100831:
> $ time ./hdbench lazyBSNull bigfile a b > /dev/null
> 0.07user 0.10system 0:00.18elapsed 96%CPU
> 
> In addition to the slowdown, the allocation behaviour has become quite bad:
> 
> ghc-6.12.3:
>       89,330,672 bytes allocated in the heap
>           15,092 bytes copied during GC
>           35,980 bytes maximum residency (1 sample(s))
>           29,556 bytes maximum slop
>                2 MB total memory in use (0 MB lost due to fragmentation)
> 
> ghc-6.13.20100831:
>      475,305,720 bytes allocated in the heap
>           89,272 bytes copied during GC
>           68,860 bytes maximum residency (1 sample(s))
>           29,444 bytes maximum slop
>                2 MB total memory in use (0 MB lost due to fragmentation)

Can you put your benchmark code somewhere?  Likely a GHC regression.

-- Don


More information about the Glasgow-haskell-users mailing list