#13739: Very slow linking of profiled executables -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Oops, please ignore the noise about `-fwhole-archive-hs-libs` above. I forgot that the commit which introduced `-fwhole-archive-hs-libs` (a6874e546294173c166859769dd8054887a6ded7) didn't come until //after// 283acec1d7307fdbd8cd7b3f1d984a036366d6b4 (Make split sections by default work again), so the times I got above were just from GHC erroring out. (I suppressed the stdout/stderr to avoid flooding my terminal, so I didn't notice this happening.) Also, an observation that I meant to make earlier is that I think that b207b536ded40156f9adb168565ca78e1eef2c74 (Generalize kind of the (->) tycon), which I singled out in comment:9, is a red herring. I think commit 283acec1d7307fdbd8cd7b3f1d984a036366d6b4 (Make split sections by default work again) is the true culprit that causes a bad constant factor for each additional linked symbol, and commit b207b536ded40156f9adb168565ca78e1eef2c74 just happened to add a bunch of extra symbols. This is further evidenced by the fact that reverting 283acec1d7307fdbd8cd7b3f1d984a036366d6b4 alone brings the link time back down to the same as what I get with GHC 8.0.2. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13739#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler