GitLab

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.