Karel Gardas wrote

7.10.1 should IIRC support some kind of DWARF debugging information and IIRC it was mentioned and decided on ghc devel that the libraries will ship with some DWARF to easy debugging

-- but takes me lightly on it and verify if this is the case since I may be completely off and this may apply to GHC HEAD and not to 7.10.x

Stripped all debugging, didn't help. -- View this message in context: http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067p5768077.... Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

Roman Cheplyaka-2 wrote

I'm not denying (or confirming) your claim, but it would look more legitimate if you compared the same version of Cabal compiled with different versions of GHC.

At least some of this bloat could be because Cabal simply gained more code.

Tricky to test that because of dependencies and global package db. I haven't measured the amount of code in Cabal, but I doubt it's increased that much, and there has been a big jump in the installed size of every library. -- View this message in context: http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067p5768080.... Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

How much of this might be attributable to longer linker symbol names? Ghc 7.10 object code does have larger symbols! Is there a way to easily tabulate that? On Apr 1, 2015 9:40 AM, "Jeremy" wrote:

Roman Cheplyaka-2 wrote

...

I'm not denying (or confirming) your claim, but it would look more legitimate if you compared the same version of Cabal compiled with different versions of GHC.

At least some of this bloat could be because Cabal simply gained more code.

I was going to prove you wrong by identifying packages which have barely changed for 7.10 ... and found that those packages were a similar size to their 7.8 versions.

However, the size increase in other packages is huge, and "simply gained more code" doesn't seem like an adequate explanation, with some package more than doubling.

Here are the full results:

7.8:

34M Cabal-1.18.1.5 3.8M array-0.5.0.0 50M base-4.7.0.2 52M bin 368K bin-package-db-0.0.0.0 2.7M binary-0.7.1.0 5.4M bytestring-0.10.4.0 9.4M containers-0.5.5.1 196K deepseq-1.3.0.2 608K directory-1.2.1.0 740K filepath-1.3.0.2 105M ghc-7.8.4 2.7M ghc-prim-0.3.1.0 8.7M haskeline-0.7.1.2 3.4M hoopl-3.10.0.1 1020K hpc-0.6.0.1 556K integer-gmp-0.5.1.0 680K pretty-1.1.1.1 684K process-1.2.0.0 1.6M rts-1.0 13M template-haskell-2.9.0.0 1.4M terminfo-0.4.0.0 6.1M time-1.4.2 4.4M transformers-0.3.0.0 5.2M unix-2.7.0.1

7.10:

83M Cabal_HWT8QvVfJLn2ubvobpycJY 3.7M array_FaHmcBFfuRM8kmZLEY8D5S 52M base_I5BErHzyOm07EBNpKBEeUv 56M bin 2.9M binar_EKE3c9Lmxb3DQpU0fPtru6 832K binpa_JNoexmBMuO8C771QaIy3YN 5.7M bytes_6vj5EoliHgNHISHCVCb069 11M conta_47ajk3tbda43DFWyeF3oHQ 432K deeps_FpR4obOZALU1lutWnrBldi 912K direc_3TcTyYedch32o1zTH2MR00 796K filep_5HhyRonfEZoDO205Wm9E4h 113M ghc_EMlWrQ42XY0BNVbSrKixqY 2.9M ghcpr_8TmvWUcS1U1IKHT0levwg3 8.9M haske_IlDhIe25uAn0WJY379Nu1M 3.4M hoopl_JxODiSRz1e84NbH6nnZuUk 1.1M hpc_CmUUQl5bURfBueJrdYfNs3 1.3M integ_2aU3IZNMF9a7mQ0OzsZ0dS 1.8M prett_7jIfj8VCGFf1WS0tIQ1XSZ 764K proce_0hwN3CTKynhHQqQkChnSdH 1.7M rts 19M templ_BVMCZyLwIlfGfcqqzyUAI8 1.4M termi_7qZwBlx3clR8sTBilJl253 6.2M time_Hh2clZW6in4HpYHx5bLtb7 7.3M trans_ALYlebOVzVI4kxbFX5SGhm 5.4M unix_G4Yo1pNtYrk8nCq1cx8P9d

-- View this message in context: http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067p5768083.... Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Yes, this does seem like a potential culprit, although we did do some measurements and I didn't think it was too bad. Maybe we were wrong! Edward Excerpts from Jeremy's message of 2015-04-01 07:26:55 -0700:

Carter Schonwald wrote

...

How much of this might be attributable to longer linker symbol names? Ghc 7.10 object code does have larger symbols! Is there a way to easily tabulate that?

That would explain why the hi files have also increased many-fold. Is there any way to avoid the larger symbols?

Very strange. If I download Cabal from hackage and build it with 'cabal build' the bloat disappears. cabal build: 18M HSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.o 21M libHSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.a /usr/local/lib/ghc-7.10.1: 23M HSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.o 53M libHSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.a This is my build.mk: SRC_HC_OPTS = -O -H64m GhcRTSWays = thr HADDOCK_DOCS = NO GhcHcOpts = GhcLibWays = v DYNAMIC_GHC_PROGRAMS = NO This is the same as I used for 7.8 without issue, except the addition of GhcHcOpts (because 7.8 ignored the default). -- View this message in context: http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067p5768133.... Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

Woops, never mind. On Apr 2, 2015 7:53 AM, "Carter Schonwald" wrote:

Do you have profiling enabled locally? On Apr 2, 2015 5:19 AM, "Jeremy" wrote:

...

Very strange. If I download Cabal from hackage and build it with 'cabal build' the bloat disappears.

cabal build:

18M HSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.o 21M libHSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.a

/usr/local/lib/ghc-7.10.1:

23M HSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.o 53M libHSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.a

This is my build.mk:

SRC_HC_OPTS = -O -H64m GhcRTSWays = thr HADDOCK_DOCS = NO GhcHcOpts = GhcLibWays = v DYNAMIC_GHC_PROGRAMS = NO

This is the same as I used for 7.8 without issue, except the addition of GhcHcOpts (because 7.8 ignored the default).

-- View this message in context: http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067p5768133.... Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Thomas Miedema wrote:

Maybe `split-objs` is not applied?

* Stray `SplitObjs = NO` in your build.mk?

Tried adding SplitObjs = YES, didn't help

* You're on an old OS X with XCode < 3.2?

Debian Jessie -- View this message in context: http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067p5768155.... Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

Jeremy, On Thu, Apr 2, 2015 at 2:12 PM, Thomas Miedema wrote:

Maybe `split-objs` is not applied?

That suggestion was completely misguided. Compiling with `-split-objs` makes a library _grow_ in size, but makes executables that link against it _smaller_. Size of `libHSCabal-1.22.2.0` obtained by running `cabal install Cabal==1.22.2.0 --with-ghc=ghc-x.x.x (--enable-split-objs)`, on 64bit Ubuntu: default --enable-split-objs 7.8.4: 19Mb 46Mb 7.10.1: 21Mb 52Mb So the 7.10 versions are indeed somewhat larger, but I wouldn't call it ballooned or bloated. Note that a ghc build compiles the libraries with -O2 , which increases the binary size another 5% or so. All these numbers are not far off from the ones you were getting. I think you have been comparing a 7.8.4 build of Cabal without split objects, with a 7.10.1 build of Cabal with split objects. I don't think there is a bug here. -Thomas P.S. To show that binary sizes not only grow with new ghc releases, here is the same experiment with random: `cabal install random==1.0.1.1 --with-ghc=ghc-x.x.x (--enable-split-objs)` default --enable-split-objs 7.0.4: 0.94M 1.9M 7.2.2: 1.1M 2.1M 7.4.2: 0.86M 1.8M 7.6.3: 0.85M 1.8M 7.8.4: 0.76M 1.7M 7.10.1: 0.69M 1.6M

Thomas Miedema wrote

That suggestion was completely misguided. Compiling with `-split-objs` makes a library _grow_ in size, but makes executables that link against it _smaller_.

All these numbers are not far off from the ones you were getting. I think you have been comparing a 7.8.4 build of Cabal without split objects, with a 7.10.1 build of Cabal with split objects.

I don't think there is a bug here.

My GHC build is now back to the 7.8-era size. Thank you! I was wondering why programs compiled with my GHC 7.8 build were bigger than if I used an official build. Perhaps a bug in the 7.8 build system had turned off SplitObjs. -- View this message in context: http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067p5768274.... Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

It was all due to a missing -split-objs in Jeremy's 7.8 build. I updated the user's guide. The section on -split-objs now reads, with the part that is new in italic: -split-objs Tell the linker to split the single object file that would normally be generated into multiple object files, one per top-level Haskell function or type in the module. This only makes sense for libraries, where it means that executables linked against the library are smaller as they only link against the object files that they need. However, assembling all the sections separately is expensive, so this is slower than compiling normally. *Additionally, the size of the library itself **(the .a file) can be a factor of 2 to 2.5 **larger. *We use this feature for building GHC's libraries. On Mon, Apr 6, 2015 at 11:49 AM, Simon Peyton Jones wrote:

Just to check, can someone summarise the conclusion of this thread? Was it all due to -fsplit-objs? If so, should we add some notes to the user manual to explain what may happen if you use -fsplit-objs? What was the business about Cabal?

Simon

| -----Original Message----- | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Jeremy | Sent: 05 April 2015 20:30 | To: glasgow-haskell-users@haskell.org | Subject: Re: Binary bloat in 7.10 | | Thomas Miedema wrote | > That suggestion was completely misguided. Compiling with `-split-objs` | > makes a library _grow_ in size, but makes executables that link | > against it _smaller_. | > | > All these numbers are not far off from the ones you were getting. I | > think you have been comparing a 7.8.4 build of Cabal without split | > objects, with a 7.10.1 build of Cabal with split objects. | > | > I don't think there is a bug here. | | My GHC build is now back to the 7.8-era size. Thank you! | | I was wondering why programs compiled with my GHC 7.8 build were bigger | than if I used an official build. Perhaps a bug in the 7.8 build system | had turned off SplitObjs. | | | | -- | View this message in context: | http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10- | tp5768067p5768274.html | Sent from the Haskell - Glasgow-haskell-users mailing list archive at | Nabble.com. | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users