#16413: GHC bindist with DWARF support seems much slower than non-DWARF -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Comparing the DWARF and non-DWARF binary distributions, I'm seeing times for a `cabal new-build --disable-profiling --disable-library-profiling all` for a multi-library project showing e.g. 5:46.90 for DWARF, vs 3:56.40 for non-DWARF bindists. I'm assuming this is unexpected since I don't see it proclaimed loudly anywhere. I thought this was irrelevant, but I did try doing `cabal new-build ... --enable-debug-info=0` with the DWARF-supporting GHC but that didn't seem to improve compile time. I don't see anything relevant in my `~/.cabal/config`. Even more confused because I see the same slow timing (~ 5:45) for a `stack build` in the same project, yet it looks like `stack` pulls in a GHC without DWARF-compiled libs: {{{ $ readelf --debug-dump $HOME/.stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/text-1.2.3.1/libHStext-1.2.3.1-ghc8.6.3.so | grep Version $ }}} Maybe `stack` is compiling in a different way though, and the timing similarity is just a coincidence. I first noticed this when building GHC from source. It seemed that uncommenting these caused the regression (though I haven't double- checked): {{{ #GhcLibHcOpts += -g3 #GhcRtsHcOpts += -g3 }}} Attached is the project repo I tested with (again, with `cabal new-clean && cabal new-build --disable-profiling --disable-library-profiling all`). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/16413 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler