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