Full laziness is sometimes a pessimisation

I've found a case where the optimizer produces code that uses more memory and runs slower. Here's an example that contrasts the default behavior with the optimized behavior. Cale posted a comparison of GHC's core on this program (using 6.8.1) on http://hpaste.org/4133#a1.

Without optimizations: Both print statements take the same (fairly short) amount of time. [[BR]] With optimizations: The first print statement takes a lot longer, but second happens very quickly.

Essentially, it is caching the entire 10 million item list, instead of just its length.

$ cat test.hs 
f x = length [0 .. x :: Int]
main = do
    print $ f 10000000
    print $ f 10000000
$ time runhaskell test.hs 
10000001
10000001

real    0m0.682s
user    0m0.636s
sys     0m0.044s
$ ghc --make test
[1 of 1] Compiling Main             ( test.hs, test.o )
Linking test ...
$ time ./test 
10000001
10000001

real    0m0.438s
user    0m0.428s
sys     0m0.008s

$ rm test test.hi test.o
$ ghc --make test -O
[1 of 1] Compiling Main             ( test.hs, test.o )
Linking test ...
$ time ./test 
10000001
10000001

real    0m2.447s
user    0m2.200s
sys     0m0.224s

Trac metadata

Trac field	Value
Version	6.8.1
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system	Unknown
Architecture	Unknown