|
#6042: GHC is bloated
---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 7.6.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ I noticed today that our binary dists are getting bigger: {{{ -rw-rw-r-- 1 simonmar GHC 118924739 2010-11-17 04:02 ghc-7.0.1-i386 -unknown-linux.tar.bz2 -rw-rw-r-- 1 simonmar GHC 112074889 2011-03-02 04:19 ghc-7.0.2-i386 -unknown-linux.tar.bz2 -rw-rw-r-- 1 simonmar GHC 109012585 2011-03-27 05:21 ghc-7.0.3-i386 -unknown-linux.tar.bz2 -rw-rw-r-- 1 simonmar GHC 109012197 2011-06-15 04:25 ghc-7.0.4-i386 -unknown-linux.tar.bz2 -rw-rw-r-- 1 simonmar GHC 115102248 2011-08-10 03:17 ghc-7.2.1-i386 -unknown-linux.tar.bz2 -rw-rw-r-- 1 simonmar GHC 114428608 2011-11-10 04:28 ghc-7.2.2-i386 -unknown-linux.tar.bz2 -rw-rw-r-- 1 simonmar GHC 123417972 2012-04-20 04:23 ghc-7.4.1.20120416-i386-unknown-linux.tar.bz2 -rw-rw-r-- 1 simonmar GHC 144861355 2012-04-18 06:25 ghc-7.5.20120413-i386 -unknown-linux.tar.bz2 }}} I looked into the difference between 7.0.4 and 7.4.1, and found that it seems to be mostly caused by GHC itself getting bigger: {{{ -rwxrwxr-x simonmar/GHC 31280127 2011-06-14 19:59 ghc-7.0.4/ghc/stage2/build/tmp/ghc-stage2 -rwxrwxr-x simonmar/GHC 41050757 2012-04-19 20:12 ghc-7.4.1/ghc/stage2/build/tmp/ghc-stage2 }}} the GHC binary is 25% larger, and the binary dist contains several copies of GHC (.a, _p.a, .so, the GHC binary, haddock). We didn't add 25% more code to GHC between 7.0.4 and 7.4.1, so why is it 25% larger? This increase isn't reflected in other libraries - in fact, the base package is smaller in 7.4.1 than 7.0.4. I have a horrid feeling that this is due to heavy use of INLINE/INLINABLE in `containers`, but I hope I'm wrong. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6042> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler _______________________________________________ Glasgow-haskell-bugs mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs |
|
#6042: GHC is bloated
---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 7.6.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by igloo): ghc-7.5.20120413 is bigger because it contains dph, parallel, primitive, random, stm and vector. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6042#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler _______________________________________________ Glasgow-haskell-bugs mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs |
|
In reply to this post by GHC
#6042: GHC is bloated
---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 7.6.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by milan): Cheers, I do not believe INLINABLE in containers is the villain here :) Nevertheless, I am measuring its effect, and will post the results later today. BTW, GHC-head is seeing INLINABLE only (except some trivial INLINE methods like empty = Nil). -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6042#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler _______________________________________________ Glasgow-haskell-bugs mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs |
|
In reply to this post by GHC
#6042: GHC is bloated
---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 7.6.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by simonmar): milan: great (I hoped by CC'ing you I might prompt you to run some tests :-) My worry is that INLINABLE is causing us to specialise e.g. `Data.IntMap.lookup` every time it is used. If that is the case, then we should write a wrapper module around `Data.IntMap` and use it everywhere in GHC. We do this to some extent (`UniqFM`) but not everywhere, and we should also check that in the case of `UniqFM` it really is sharing the specialisations as we expect. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6042#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler _______________________________________________ Glasgow-haskell-bugs mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs |
|
In reply to this post by GHC
#6042: GHC is bloated
---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 7.6.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by simonmar): igloo: I wasn't expecting the extra packages to be in the bindist. Looking at the code it seems that `InstallExtraPackages` should be `NO`, which ought to prevent them going into the bindist. Any idea what's going on? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6042#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler _______________________________________________ Glasgow-haskell-bugs mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs |
|
In reply to this post by GHC
#6042: GHC is bloated
---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 7.6.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by milan): The INLINABLE is being used only on Map and Set. The idea is that Data.Map.lookup is specialized if it is used with a known class instance (e.g., when using lookup on 'Map Int something'). In that case, a specialization is created, together with a rewrite rule which causes that this specialization is used for further lookups on 'Map Int something'. This rule is used in the same module and also in all modules importing this one. If we decide to write a wrapper, it would have to mention all key types for which a Map or Set is being used. But if I recall, Maps and Sets are not frequently used. We'll see from the numbers. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6042#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler _______________________________________________ Glasgow-haskell-bugs mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs |
|
In reply to this post by GHC
#6042: GHC is bloated
---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 7.6.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by simonpj): INLINABLE should only mean that you specialise `Data.Map.lookup` once per '''module''', not once per '''call'''. Moreover if A imports B (transitively), and B has specialised `Data.Map.lookup` at `Int`, then A should not re-specialise it. So it's pretty good actually. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6042#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler _______________________________________________ Glasgow-haskell-bugs mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs |
|
In reply to this post by GHC
#6042: GHC is bloated
---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 7.6.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by simonmar): milan, simonpj: yes, I know how specialisations are shared. I'm worried that we might not be getting the sharing because there isn't a module higher up in the hierarchy that creates the specialisation, so that we get one copy of `Data.Map.lookup` in each of the leaf modules. But anyway it does seem unlikely that this alone could be responsible for GHC getting heavier by 10MB, so further investigation is definitely called for. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6042#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler _______________________________________________ Glasgow-haskell-bugs mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs |
|
In reply to this post by GHC
#6042: GHC is bloated
---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 7.6.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by milan): I compiled current GHC head, 7.5.20120425, on x86_64. In all cases I did a clean build with GhcLibWays = v and measured size of stripped ghc-stage2: {{{ containers used | ghc-stage2 size | change against first line -----------------------------------------------+-----------------+------------------------- default containers from GHC tree | 35888944 | INLINABLE pragma removed | 35705456 | -0.51% INLINABLE pragma removed, INLINE folds removed | 35401680 | -1.35% INLINABLE changed to INLINE | 35973712 | +0.23% }}} The INLINABLE pragma itself is causing ~183k increase in size (0.5%). If INLINE were used instead of INLINABLE, the increase would be ~268k. So there is some improvement in using INLINABLE instead of INLINE, but not very big. Another issue is that containers do INLINE folds. This is a big performance win in some circumstances, especially when the combining function is small and its unfolding is known. This causes another ~303k increase in size (0.8%). BTW, Data.List.foldr is INLINEd too. So although there is some code growth, it is not enormous (at least in my opinion). -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6042#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler _______________________________________________ Glasgow-haskell-bugs mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs |
|
In reply to this post by GHC
#6042: GHC is bloated
---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 7.6.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by milan): BTW, when I preparing for the advanced functional programming course, I found out that the following code {{{ module Test where factorial :: Int -> Int factorial n | n > 0 = f n 1 where f 0 acc = acc f n acc = f (n-1) (n * acc) }}} produces the following STG, on both GHC 7.0.4 and 7.4.1, with unused method `factorial_f`: {{{ Test.factorial2 = \u srt:(0,*bitmap*) [] Control.Exception.Base.patError "a.hs:(4,1)-(6,35)|function factorial"; SRT(Test.factorial2): [Control.Exception.Base.patError] Test.$wf = \r [ww_srk ww1_sro] case ww_srk of wild_srm { __DEFAULT -> case *# [wild_srm ww1_sro] of sat_srK { __DEFAULT -> case -# [wild_srm 1] of sat_srL { __DEFAULT -> Test.$wf sat_srL sat_srK; }; }; 0 -> ww1_sro; }; SRT(Test.$wf): [] Test.factorial_f = \r [w_srs w1_srv] case w_srs of w2_srN { GHC.Types.I# ww_sry -> case w1_srv of w3_srM { GHC.Types.I# ww1_srz -> case Test.$wf ww_sry ww1_srz of ww2_srB { __DEFAULT -> GHC.Types.I# [ww2_srB]; }; }; }; SRT(Test.factorial_f): [] Test.factorial1 = NO_CCS GHC.Types.I#! [1]; SRT(Test.factorial1): [] Test.factorial = \r srt:(0,*bitmap*) [n_srD] case n_srD of wild_srP { GHC.Types.I# x_srG -> case ># [x_srG 0] of wild1_srO { GHC.Types.False -> Test.factorial2; GHC.Types.True -> case Test.$wf x_srG 1 of ww_srJ { __DEFAULT -> GHC.Types.I# [ww_srJ]; }; }; }; SRT(Test.factorial): [Test.factorial2] }}} The `Test.factorial_f` appears also in asm and in the object file. I am not saying this is responsible for 10MB code size increase, as already GHC 7.0.4 behaves this way, and `--split-objs` should avoid linking it into the final executable. But I was surprised. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6042#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler _______________________________________________ Glasgow-haskell-bugs mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs |
|
In reply to this post by GHC
#6042: GHC is bloated
---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 7.6.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by simonmar): milan: Many thanks for running the tests, and sorry for wasting your time. At least we have ruled out INLINE/INLINABLE as the cause of the bloat. (I'm still not keen on the INLINE folds: I would rather they were marked INLINABLE and the user explicitly chooses to inline by using `inline fold`. This could be mentioned in the docs.) Thanks for raising the issue with the `factorial` example, I've made a separate ticket: #6047 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6042#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler _______________________________________________ Glasgow-haskell-bugs mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs |
|
In reply to this post by GHC
#6042: GHC is bloated
---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 7.6.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by igloo): Replying to [comment:4 simonmar]: > igloo: I wasn't expecting the extra packages to be in the bindist. Looking at the code it seems that `InstallExtraPackages` should be `NO`, which ought to prevent them going into the bindist. Any idea what's going on? I think it stops them being installed, but not being put into bindists. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6042#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler _______________________________________________ Glasgow-haskell-bugs mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs |
|
In reply to this post by GHC
#6042: GHC is bloated
---------------------------------+------------------------------------------ Reporter: simonmar | Owner: igloo Type: bug | Status: new Priority: highest | Milestone: 7.6.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by simonpj): * owner: => igloo * priority: high => highest -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6042#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler _______________________________________________ Glasgow-haskell-bugs mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs |
|
In reply to this post by GHC
#6042: GHC is bloated
---------------------------------+------------------------------------------ Reporter: simonmar | Owner: pcapriotti Type: bug | Status: new Priority: highest | Milestone: 7.6.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by igloo): * owner: igloo => pcapriotti Comment: Paolo, now #6104 is out of the way, could you take a look at this please? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6042#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler _______________________________________________ Glasgow-haskell-bugs mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs |
|
In reply to this post by GHC
#6042: GHC is bloated
---------------------------------+------------------------------------------ Reporter: simonmar | Owner: pcapriotti Type: bug | Status: new Priority: highest | Milestone: 7.6.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by simonpj): Paolo writes: I've spent some time looking at #6042, but with not much success. Here's how the GHC executable size progressed with the past few releases: {{{ 7.0 31228882 7.2 36553006 7.4 43645088 7.6 45291472 head 45443324 }}} Here are listings showing module sizes for 7.0, 7.2 and 7.4. CmmParse has increased dramatically between 7.0 and 7.2, but then it went back down in later releases. There doesn't seem anything else sticking out there, it seems that the growth is spread mostly uniformly across modules. {{{ module 7.0 7.2 7.4 HsExpr.o 1314060 1372352 1432064 DynFlags.o 908576 1044420 1144280 Parser.o 844896 862364 745108 HsDecls.o 712864 748692 838848 ZipDataflow.o 572676 - - Lexer.o 550864 810460 599104 DsMeta.o 532032 543612 526708 CmmParse.o 511732 2548668 492312 HsBinds.o 486876 487872 453996 PrimOp.o 337680 494072 547644 }}} Not sure if this is helpful, but here's a summary of the differences in section sizes between 7.0 and 7.2: {{{ text +2536464 14.3 % rodata +1494840 151.5 % data + 190880 17.9 % }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6042#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler _______________________________________________ Glasgow-haskell-bugs mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs |
|
In reply to this post by GHC
#6042: GHC is bloated
---------------------------------+------------------------------------------ Reporter: simonmar | Owner: pcapriotti Type: bug | Status: new Priority: highest | Milestone: 7.6.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by simonpj): So if it isn't the big modules, then either it must be the small modules, or else we are linking libraries that we weren't using in 7.0. I think it'd be worth finding out which and why Simon -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6042#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler _______________________________________________ Glasgow-haskell-bugs mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs |
|
In reply to this post by GHC
#6042: GHC is bloated
---------------------------------+------------------------------------------ Reporter: simonmar | Owner: pcapriotti Type: bug | Status: new Priority: highest | Milestone: 7.6.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by pcapriotti): I haven't looked at the libraries, but libghc.a alone has increased in size between 7.0 and 7.4. The increase between 7.0 and 7.2 seems to be mostly due to the blowup of CmmParse and related modules (ParserCore, Lexer). That went away in 7.4, but libghc.a is still as large in 7.4 as 7.2. Looking at the deltas between 7.0 and 7.4 isn't particularly illuminating, though. Some modules increased, some shrinked, giving a positive total, and it's hard to draw any conclusion just by looking at the sizes. I attached a CSV with sizes by module, sorted by difference between 7.0 and 7.4. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6042#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler _______________________________________________ Glasgow-haskell-bugs mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs |
|
In reply to this post by GHC
#6042: GHC is bloated
---------------------------------+------------------------------------------ Reporter: simonmar | Owner: pcapriotti Type: bug | Status: new Priority: highest | Milestone: 7.6.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by pcapriotti): Here is the output of `size` for stage1, obtained by compiling with those 3 versions of GHC, with and without split-objects on the libraries: {{{ SplitObjs=YES text data bss dec hex filename 7.0.4 18690071 1181180 13384 19884635 12f6a5b inplace/lib/ghc- stage1 7.4.2 19205941 1257480 13364 20476785 1387371 inplace/lib/ghc- stage1 7.6.0 21763908 1482588 13364 23259860 162ead4 inplace/lib/ghc- stage1 }}} {{{ SplitObjs=NO 7.0.4 22128013 1410852 13352 23552217 16760d9 inplace/lib/ghc- stage1 7.4.2 22353138 1469344 13332 23835814 16bb4a6 inplace/lib/ghc- stage1 7.6.0 21763908 1482588 13364 23259860 162ead4 inplace/lib/ghc- stage1 }}} So it looks like `SplitObjs` isn't doing anything on 7.6. Attached is a csv with sizes module by module (as reported by `size`). -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6042#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler _______________________________________________ Glasgow-haskell-bugs mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs |
|
In reply to this post by GHC
#6042: GHC is bloated
---------------------------------+------------------------------------------ Reporter: simonmar | Owner: pcapriotti Type: bug | Status: new Priority: highest | Milestone: 7.6.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by pcapriotti): The comment showing a large difference in size when building with 7.6 (http://hackage.haskell.org/trac/ghc/ticket/6042#comment:17) is actually incorrect. I ran the builds again, and I got (output of `ls -l`): {{{ 7.0.4 32933655 7.4.2 33950489 7.6.0 34185444 }}} Sorry about the confusion. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6042#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler _______________________________________________ Glasgow-haskell-bugs mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs |
|
In reply to this post by GHC
#6042: GHC is bloated
---------------------------------+------------------------------------------ Reporter: simonmar | Owner: pcapriotti Type: bug | Status: new Priority: highest | Milestone: 7.6.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by igloo): So what's the status of this ticket? Is there still a problem to be investigated? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6042#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler _______________________________________________ Glasgow-haskell-bugs mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs |
| Powered by Nabble | Edit this page |
