Opened 13 months ago

Last modified 13 months ago

#15524 new bug

Performance regression when using the GHC API to evaluate code compared to 8.4

Reported by: vaibhavsagar Owned by:
Priority: normal Milestone: 8.6.1
Component: Compiler Version: 8.6.1-beta1
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Runtime performance bug Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description (last modified by vaibhavsagar)

I've been in the process of updating IHaskell to support GHC 8.6 and the test suite has become agonisingly slow as compared to GHC 8.4 and below. I've been able to work around this by using --enable-executable-dynamic as suggested by christiaanb on #ghcbut I thought this was worth reporting as a bug.

To reproduce this on a Linux installation with Nix:

  1. git clone https://github.com/gibiansky/IHaskell
  2. cd IHaskell
  3. git checkout 6058cd4fac01a2023dbd09d174f1f8d4c36e7475
  4. Comment out --enable-executable-dynamic in release-8.6.nix
  5. nix-build release-8.6.nix

Change History (7)

comment:1 Changed 13 months ago by mpickering

The git hash of the commit for the repro is ad0ec26cc976b7f263cc4781eead264b7080cc4e just in case the branch mutates.

comment:2 Changed 13 months ago by vaibhavsagar

Description: modified (diff)

I've since tried this with GHC 8.6.1-beta1 and am seeing the same behaviour.

comment:3 Changed 13 months ago by vaibhavsagar

Description: modified (diff)

comment:4 Changed 13 months ago by simonpj

"Agonisingly slow" sounds bad. What exactly does --enable-executable-dynamic do? Does anyone have a theory about what's going on?

comment:5 Changed 13 months ago by vaibhavsagar

To quantify, without --enable-executable-dynamic the test suite takes ~300s to run and with it enabled that time goes down to ~20s.

comment:6 Changed 13 months ago by darchon

--enable-executable-dynamic is the Cabal flag to ensure that the resulting executable is dynamically linked against all (Haskell) libraries. Among other things, it ensures that GHC is called with -dynamic to produce the executable.

By default, Cabal/GHC produces executables that are statically linked again (Haskell) libraries.

N.B. For Clash, I've had to enable dynamic linking since GHC 8.2 in order not to incur the performance penalty mentioned in this ticket. Since GHC itself is also dynamically linked (at least it is on Linux) I was never too bothered with having to dynamically link the Clash executables. Anyhow, this makes me wonder if we were to statically link the GHC executable (on linux) whether GHC will incur the same performance overhead as us GHC API users.

comment:7 Changed 13 months ago by bgamari

This is quite interesting; it would be helpful if someone could paste a few backtraces from GDB (or perf a perf profile). If anything I would expect dynamic linking to make things slightly slower, not faster.

Note: See TracTickets for help on using tickets.