[GHC] #11285: Split objects makes static linking really slow (was: Static linking is really slow sometimes)

[GHC]

#11285: Split objects makes static linking really slow
-------------------------------------+-------------------------------------
        Reporter:  ezyang            |                Owner:
            Type:  feature request   |               Status:  new
        Priority:  high              |            Milestone:
       Component:  Compiler          |              Version:  7.11
  (Linking)                          |
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Compile-time      |  Unknown/Multiple
  performance bug                    |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Changes (by ezyang):

 * type:  bug => feature request


Old description:

> I'm testing on Cabal `Setup.hs`, which links against Cabal.
>
> On a beefy machine with many cores and lots of RAM, I see a x2 regression
> in linking time from GHC 7.10.2 to GHC 8.0 (a recent HEAD) using GNU ld
> (not gold):
>
> {{{
> [ezyang at hs01 ezyang]$ rm A; time ghc --make A.hs -fforce-recomp
> [1 of 1] Compiling Main             ( A.hs, A.o )
> Linking A ...
>
> real    0m1.273s
> user    0m0.990s
> sys     0m0.210s
>
> [ezyang at hs01 ezyang]$ rm A; time ghc-8.0/usr/bin/ghc --make A.hs -fforce-
> recomp
> [1 of 1] Compiling Main             ( A.hs, A.o )
> Linking A ...
>
> real    0m3.270s
> user    0m2.727s
> sys     0m0.523s
> }}}
>
> On a puny eight year-old laptop, I see a x2 regression from 7.6 to 7.10
> (with not much change with 8.0)
>
> {{{
> ezyang at sabre:~$ rm A; time ghc --make -O0 A.hs -fforce-recomp
> rm: cannot remove ‘A’: No such file or directory
> [1 of 1] Compiling Main             ( A.hs, A.o )
> Linking A ...
>
> real    0m3.058s
> user    0m1.860s
> sys     0m1.164s
> ezyang at sabre:~$ rm A; time ghc-7.10 --make -O0 A.hs -fforce-recomp
> [1 of 1] Compiling Main             ( A.hs, A.o )
> Linking A ...
>
> real    0m7.139s
> user    0m4.616s
> sys     0m2.488s
>
> }}}
>
> There must be something which is causing the linker to run slowly in one
> case, and quickly in the other. It would be really good to figure out
> what this is. Slow linking is NOT NICE.

New description:

 Here's a comparison of a few builds of `Setup.hs` using GHC 7.10.3. In the
 first case, I am building using a version of GHC with split objects
 disabled on all libraries. In the second, split objects were enabled but
 Cabal was compiled without split objects. In the third, Cabal was built
 with split objects.

 {{{
 [ezyang at hs01 ezyang]$ rm Setup; time ghc-7.10-nosplitobjs/inplace/bin/ghc-
 stage2 --make Setup.hs -O0
 rm: cannot remove ‘Setup’: No such file or directory
 [1 of 1] Compiling Main             ( Setup.hs, Setup.o )
 Linking Setup ...

 real    0m0.950s
 user    0m0.757s
 sys     0m0.163s
 [ezyang at hs01 ezyang]$ rm Setup; time ghc --make Setup.hs -O0
 Linking Setup ...

 real    0m1.209s
 user    0m0.973s
 sys     0m0.177s
 [ezyang at hs01 ezyang]$ rm Setup; time ghc -no-user-package-db --make
 Setup.hs -O0
 [1 of 1] Compiling Main             ( Setup.hs, Setup.o )
 [Distribution.Simple changed]
 Linking Setup ...

 real    0m3.136s
 user    0m2.693s
 sys     0m0.407s
 }}}

 In my experience, Cabal is the MOST expensive library to compile with
 split objects (on my laptop, this is an x2 difference in link time); among
 base libraries, ld.gold visibly hitches when it has to link base.

 Slow link times make for unpleasant experience for users, especially since
 we don't compile executables as dynamic by default. To make matters worse,
 split object compiled boot libraries represent a mandatory tax for anyone
 using static linking, because it's *not possible* to swap out those static
 archives with non-split objects ones.

 Could we enhance GHC to support running the linker in a "fast mode", where
 we ask the linker to treat archives as atomic units and not try to
 optimize for binary size? We can keep the current slow mode for production
 executables that people want to ship.

--

Comment:

 I've diagnosed that split objects is the problem. I've rewritten the
 description to reflect this.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11285#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler