Significant size increase in GHC HEAD's static library sizes

Hello * While generating .deb packages of various GHC 7.x releases[1] I noticed a peculiar jump in the resulting binary .deb package for GHC HEAD (about +50% wrt to GHC 7.6.3); at first I thought this was mostly due to having enabled shared libaries for that particular package, but then I compared the .a sizes, and noticed some significant increases in object sizes: For instance, Cabal's library file jumps to: 24M ghc-6.12.3/Cabal-1.8.0.6/libHSCabal-1.8.0.6.a 27M ghc-7.0.4/Cabal-1.10.2.0/libHSCabal-1.10.2.0.a 28M ghc-7.2.2/Cabal-1.12.0/libHSCabal-1.12.0.a 27M ghc-7.4.2/Cabal-1.14.0/libHSCabal-1.14.0.a 28M ghc-7.6.3/Cabal-1.16.0/libHSCabal-1.16.0.a 41M ghc-7.7.20131018/Cabal-1.18.1.1/libHSCabal-1.18.1.1.a A similiar increase can be observed for the ghc library: 56M 6.12.3/lib/ghc-6.12.3/ghc-6.12.3/libHSghc-6.12.3.a 65M 7.0.4/lib/ghc-7.0.4/ghc-7.0.4/libHSghc-7.0.4.a 73M 7.2.2/lib/ghc-7.2.2/ghc-7.2.2/libHSghc-7.2.2.a 78M 7.4.2/lib/ghc-7.4.2/ghc-7.4.2/libHSghc-7.4.2.a 76M 7.6.3/lib/ghc-7.6.3/ghc-7.6.3/libHSghc-7.6.3.a 103M head/lib/ghc-7.7.20131018/ghc-7.7.20131018/libHSghc-7.7.20131018.a But there are other libraries, such as `base` that don't show this kind of size increase. I haven't had time to investigate, but I wanted to report my observation in case somebody has an explanation for this. [1]: https://launchpad.net/~hvr/+archive/ghc Cheers, hvr

On 20/10/2013 22:18, Herbert Valerio Riedel wrote:
Hello *
While generating .deb packages of various GHC 7.x releases[1] I noticed a peculiar jump in the resulting binary .deb package for GHC HEAD (about +50% wrt to GHC 7.6.3); at first I thought this was mostly due to having enabled shared libaries for that particular package, but then I compared the .a sizes, and noticed some significant increases in object sizes:
For instance, Cabal's library file jumps to:
24M ghc-6.12.3/Cabal-1.8.0.6/libHSCabal-1.8.0.6.a 27M ghc-7.0.4/Cabal-1.10.2.0/libHSCabal-1.10.2.0.a 28M ghc-7.2.2/Cabal-1.12.0/libHSCabal-1.12.0.a 27M ghc-7.4.2/Cabal-1.14.0/libHSCabal-1.14.0.a 28M ghc-7.6.3/Cabal-1.16.0/libHSCabal-1.16.0.a 41M ghc-7.7.20131018/Cabal-1.18.1.1/libHSCabal-1.18.1.1.a
A similiar increase can be observed for the ghc library:
56M 6.12.3/lib/ghc-6.12.3/ghc-6.12.3/libHSghc-6.12.3.a 65M 7.0.4/lib/ghc-7.0.4/ghc-7.0.4/libHSghc-7.0.4.a 73M 7.2.2/lib/ghc-7.2.2/ghc-7.2.2/libHSghc-7.2.2.a 78M 7.4.2/lib/ghc-7.4.2/ghc-7.4.2/libHSghc-7.4.2.a 76M 7.6.3/lib/ghc-7.6.3/ghc-7.6.3/libHSghc-7.6.3.a 103M head/lib/ghc-7.7.20131018/ghc-7.7.20131018/libHSghc-7.7.20131018.a
But there are other libraries, such as `base` that don't show this kind of size increase. I haven't had time to investigate, but I wanted to report my observation in case somebody has an explanation for this.
Often this is just due to there being more code. For example GHC now includes hoopl, and other new stuff. Cabal 1.18 has parallel builds and sandboxes. I'd be worried if the nofib results showed a significant increase in binary sizes for individual modules - if someone could run a couple of nofibs with 7.6.3 and HEAD and post the results that would be great. The new codegen should be generating binary sizes that are on average the same as the old codegen (+/- a few percent in individual cases, last time I measured it). Cheers, Simon
participants (2)
-
Herbert Valerio Riedel
-
Simon Marlow