Re: Binary bloat in 7.10
Thomas Miedema wrote It was all due to a missing -split-objs in Jeremy's 7.8 build. For the record, this appears to have been a bug in the 7.8 build system, as SplitObjs is supposed to be on by default. I only noticed when building 7.10, where the default was correct, and didn't understand why the GHC libraries has ballooned. -- View this message in context: http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067p5768377.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
Re: Binary bloat in 7.10
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 simo...@microsoft.com 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- | boun...@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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
RE: Binary bloat in 7.10
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- | boun...@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
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
Re: Binary bloat in 7.10
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.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
Re: Binary bloat in 7.10
Jeremy, On Thu, Apr 2, 2015 at 2:12 PM, Thomas Miedema thomasmied...@gmail.com 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.94M1.9M 7.2.2: 1.1M 2.1M 7.4.2: 0.86M1.8M 7.6.3: 0.85M1.8M 7.8.4: 0.76M1.7M 7.10.1: 0.69M1.6M ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Binary bloat in 7.10
Great sleuthing!! Thanks for pinning down whats going on! On Apr 2, 2015 8:48 PM, Thomas Miedema thomasmied...@gmail.com wrote: Jeremy, On Thu, Apr 2, 2015 at 2:12 PM, Thomas Miedema thomasmied...@gmail.com 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.94M1.9M 7.2.2: 1.1M 2.1M 7.4.2: 0.86M1.8M 7.6.3: 0.85M1.8M 7.8.4: 0.76M1.7M 7.10.1: 0.69M1.6M ___ 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
Re: Binary bloat in 7.10
Maybe `split-objs` is not applied? * Stray `SplitObjs = NO` in your build.mk? * You're on an old OS X with XCode 3.2? * Build system bug? On Thu, Apr 2, 2015 at 11:19 AM, Jeremy volderm...@hotmail.com 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.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
Re: Binary bloat in 7.10
Do you have profiling enabled locally? On Apr 2, 2015 5:19 AM, Jeremy volderm...@hotmail.com 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.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
Re: Binary bloat in 7.10
Woops, never mind. On Apr 2, 2015 7:53 AM, Carter Schonwald carter.schonw...@gmail.com wrote: Do you have profiling enabled locally? On Apr 2, 2015 5:19 AM, Jeremy volderm...@hotmail.com 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.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
Re: Binary bloat in 7.10
Building with https://downloads.haskell.org/~ghc/7.10.1/ghc-7.10.1-src.tar.xz -- View this message in context: http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067p5768156.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
Re: Binary bloat in 7.10
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.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
Binary bloat in 7.10
Why do the 7.10 libraries take up so much more space than 7.8? For example, using the same build options and strip --strip-unneeded, 7.8 leaves me with 15M libHSCabal-1.18.1.5.a 17M HSCabal-1.18.1.5.o whereas 7.10 balloons to 23M HSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.o 53M libHSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.a -- View this message in context: http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067.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
Re: Binary bloat in 7.10
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.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
Re: Binary bloat in 7.10
On 01/04/15 12:30, Jeremy wrote: Why do the 7.10 libraries take up so much more space than 7.8? For example, using the same build options and strip --strip-unneeded, 7.8 leaves me with 15M libHSCabal-1.18.1.5.a 17M HSCabal-1.18.1.5.o whereas 7.10 balloons to 23M HSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.o 53M libHSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.a 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. Roman ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Binary bloat in 7.10
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 Karel On 04/ 1/15 11:30 AM, Jeremy wrote: Why do the 7.10 libraries take up so much more space than 7.8? For example, using the same build options and strip --strip-unneeded, 7.8 leaves me with 15M libHSCabal-1.18.1.5.a 17M HSCabal-1.18.1.5.o whereas 7.10 balloons to 23M HSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.o 53M libHSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.a -- View this message in context: http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067.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
Re: Binary bloat in 7.10
It's not just binaries, even hi files have ballooned. (I should note that (stripped) executables appear to be unaffected.) -- View this message in context: http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067p5768072.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
Re: Binary bloat in 7.10
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.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
Re: Binary bloat in 7.10
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.8Marray-0.5.0.0 50M base-4.7.0.2 52M bin 368Kbin-package-db-0.0.0.0 2.7Mbinary-0.7.1.0 5.4Mbytestring-0.10.4.0 9.4Mcontainers-0.5.5.1 196Kdeepseq-1.3.0.2 608Kdirectory-1.2.1.0 740Kfilepath-1.3.0.2 105Mghc-7.8.4 2.7Mghc-prim-0.3.1.0 8.7Mhaskeline-0.7.1.2 3.4Mhoopl-3.10.0.1 1020K hpc-0.6.0.1 556Kinteger-gmp-0.5.1.0 680Kpretty-1.1.1.1 684Kprocess-1.2.0.0 1.6Mrts-1.0 13M template-haskell-2.9.0.0 1.4Mterminfo-0.4.0.0 6.1Mtime-1.4.2 4.4Mtransformers-0.3.0.0 5.2Munix-2.7.0.1 7.10: 83M Cabal_HWT8QvVfJLn2ubvobpycJY 3.7Marray_FaHmcBFfuRM8kmZLEY8D5S 52M base_I5BErHzyOm07EBNpKBEeUv 56M bin 2.9Mbinar_EKE3c9Lmxb3DQpU0fPtru6 832Kbinpa_JNoexmBMuO8C771QaIy3YN 5.7Mbytes_6vj5EoliHgNHISHCVCb069 11M conta_47ajk3tbda43DFWyeF3oHQ 432Kdeeps_FpR4obOZALU1lutWnrBldi 912Kdirec_3TcTyYedch32o1zTH2MR00 796Kfilep_5HhyRonfEZoDO205Wm9E4h 113Mghc_EMlWrQ42XY0BNVbSrKixqY 2.9Mghcpr_8TmvWUcS1U1IKHT0levwg3 8.9Mhaske_IlDhIe25uAn0WJY379Nu1M 3.4Mhoopl_JxODiSRz1e84NbH6nnZuUk 1.1Mhpc_CmUUQl5bURfBueJrdYfNs3 1.3Minteg_2aU3IZNMF9a7mQ0OzsZ0dS 1.8Mprett_7jIfj8VCGFf1WS0tIQ1XSZ 764Kproce_0hwN3CTKynhHQqQkChnSdH 1.7Mrts 19M templ_BVMCZyLwIlfGfcqqzyUAI8 1.4Mtermi_7qZwBlx3clR8sTBilJl253 6.2Mtime_Hh2clZW6in4HpYHx5bLtb7 7.3Mtrans_ALYlebOVzVI4kxbFX5SGhm 5.4Munix_G4Yo1pNtYrk8nCq1cx8P9d -- View this message in context: http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067p5768083.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
Re: Binary bloat in 7.10
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 volderm...@hotmail.com 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.8Marray-0.5.0.0 50M base-4.7.0.2 52M bin 368Kbin-package-db-0.0.0.0 2.7Mbinary-0.7.1.0 5.4Mbytestring-0.10.4.0 9.4Mcontainers-0.5.5.1 196Kdeepseq-1.3.0.2 608Kdirectory-1.2.1.0 740Kfilepath-1.3.0.2 105Mghc-7.8.4 2.7Mghc-prim-0.3.1.0 8.7Mhaskeline-0.7.1.2 3.4Mhoopl-3.10.0.1 1020K hpc-0.6.0.1 556Kinteger-gmp-0.5.1.0 680Kpretty-1.1.1.1 684Kprocess-1.2.0.0 1.6Mrts-1.0 13M template-haskell-2.9.0.0 1.4Mterminfo-0.4.0.0 6.1Mtime-1.4.2 4.4Mtransformers-0.3.0.0 5.2Munix-2.7.0.1 7.10: 83M Cabal_HWT8QvVfJLn2ubvobpycJY 3.7Marray_FaHmcBFfuRM8kmZLEY8D5S 52M base_I5BErHzyOm07EBNpKBEeUv 56M bin 2.9Mbinar_EKE3c9Lmxb3DQpU0fPtru6 832Kbinpa_JNoexmBMuO8C771QaIy3YN 5.7Mbytes_6vj5EoliHgNHISHCVCb069 11M conta_47ajk3tbda43DFWyeF3oHQ 432Kdeeps_FpR4obOZALU1lutWnrBldi 912Kdirec_3TcTyYedch32o1zTH2MR00 796Kfilep_5HhyRonfEZoDO205Wm9E4h 113Mghc_EMlWrQ42XY0BNVbSrKixqY 2.9Mghcpr_8TmvWUcS1U1IKHT0levwg3 8.9Mhaske_IlDhIe25uAn0WJY379Nu1M 3.4Mhoopl_JxODiSRz1e84NbH6nnZuUk 1.1Mhpc_CmUUQl5bURfBueJrdYfNs3 1.3Minteg_2aU3IZNMF9a7mQ0OzsZ0dS 1.8Mprett_7jIfj8VCGFf1WS0tIQ1XSZ 764Kproce_0hwN3CTKynhHQqQkChnSdH 1.7Mrts 19M templ_BVMCZyLwIlfGfcqqzyUAI8 1.4Mtermi_7qZwBlx3clR8sTBilJl253 6.2Mtime_Hh2clZW6in4HpYHx5bLtb7 7.3Mtrans_ALYlebOVzVI4kxbFX5SGhm 5.4Munix_G4Yo1pNtYrk8nCq1cx8P9d -- View this message in context: http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067p5768083.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
Re: Binary bloat in 7.10
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? -- View this message in context: http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067p5768095.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
Re: Binary bloat in 7.10
On Wed, Apr 01, 2015 at 02:30:49AM -0700, Jeremy wrote: Why do the 7.10 libraries take up so much more space than 7.8? For example, using the same build options and strip --strip-unneeded, 7.8 leaves me with That would be some kind of harsh april 1st joke, if everything compiled at that day gets a bloated data section by putting lots april strings into it. ;) Greetings, Daniel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Binary bloat in 7.10
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? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Binary bloat in 7.10
Mind you I'm just trying to come up with theories we can test, I'm not assigning blame. :) I'm not sure how to do the apples to apples comparison, but it sounds like some sleuthing Is In order. I dont have a 7.10 setup yet, but if someone can put a tarballed dist build folder for a 7.10 and the same for 7.8 for some lib that blows up,I'm happy to try to dig i n. Or I'll get things setup later this week to do the full comparison locally. On Apr 1, 2015 11:12 AM, Edward Z. Yang ezy...@mit.edu wrote: 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? ___ 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
