#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@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@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@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@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@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@hs01 ezyang]$ rm Setup; time ghc --make Setup.hs -O0 Linking Setup ... real 0m1.209s user 0m0.973s sys 0m0.177s [ezyang@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