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 |