firefly:
From Don Stewart: Summary: the suspicious lazy bytestring program works now. (constant space, and fastest overall, as expected originally)
Program 1, lazy bytestring length . filter
Yesterday: ./A +RTS -sstderr < 150M 1.01s user 0.10s system 98% cpu 1.123 total 40M allocated
* Today (fixed!): ./A +RTS -sstderr < 150M 0.26s user 0.06s system 96% cpu 0.332 total 2M allocated
Reason, deprecated array fusion mucking up the optimiser.
I think we can close this regression.
Nope. Look at the memory graphs:
hs/space-bslc8-lenfil-1: 38632 ██████████▌ | -- 38644 ██████████▌ | -- 1940 ▌ | -- 109404 █████████████████████████████▋ | -- 82324 ██████████████████████▍ | -- 109388 █████████████████████████████▋ | -- 82304 ██████████████████████▎ |
It is fixed for ghc 6.8.2 running bytestring 0.9.0.2 but not for ghc ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 6.9.20071119 and head (as of noon 2007-12-19), no matter the bytestring ^^^^^^^^^^^^ version. There are lots of memory performance bugs in ghc 6.9.
Please package this up as a bug report against GHC head. Any regression wrt. 6.8.2, using the same bytestring version, is going to be a ghc issue (not a bytestring library issue). -- Don