#4403: Huge (10 times) increase of binaries produced by GHC 7.0.0 and GHC head
--------------------------+-------------------------------------------------
Reporter: milan | Owner:
Type: bug | Status: new
Priority: normal | Component: Compiler
Version: 7.0.1 RC1 | Keywords: code bloat
Testcase: | Blockedby:
Os: Linux | Blocking:
Architecture: x86 | Failure: Other
--------------------------+-------------------------------------------------
When benchmarking Containers, I came over some suspicious increase of code
size. I reduced the test case to the following:
Compile the following trivial benchmark:
{{{
import Data.Set
import Criterion.Main
main = defaultMain [bench "set" (whnf (length . toList . fromList . concat
. replicate 10) [1..1000])]
}}}
The size of a stripped binary produced by ghc --make -O:
{{{
ghc-6.12.1: 2414128
ghc-7.0.0.20100930: 22572260
ghc-7.1.20101010: 21417316
}}}
That is nearly 10-times increase of code size. I could not figure out why.
When using only 'base' package, there is nearly no increase in code size.
The ghc-bundled libraries use -split-objs, the libraries compiled by
cabal-install are not using -split-objs in any ghc version.
I used I386. The ghc-6.12.1 is precompiled binary, ghc-7.0.0 is compiled
by ghc-6.12.1 by using default build system (configure && make, no
build.mk), ghc-7.1 is compiled by ghc-6.12.1 by using custom build.mk (but
it only sets !GhcLibWays=v).
The criterion package was compiled using 'cabal install criterion'. Latest
version 0.5.0.4 was used (vector 0.7, vector-algorithms 0.3.3, statistics
0.8.0.1). For ghc-7.0 and ghc-7.1 some minor changes to the latest hackage
versions of the deepseq, parallel, syb and vector-algorithms packages had
to be made (trivial dependency changes, code that does not type check).
!SimonMar said some of that is already corrected in darcs repos.
Can anyone reproduce this behaviour? If so, it is horrible.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4403>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
