Jeff

Great stuff!  Welcome.

I strongly urge you to keep a constantly-update status wiki page, which lists the ideas you are working on, and points to relevant resources and tickets.  An email thread like this is a good way to gather ideas, but NOT a good way to organise and track them.

Looking carefully at profiles is a good plan.  That’s the hard data!

I think that some careful investigation of IntMap (at least the bits that GHC uses heavily) would be a good idea.  Clearly we spend a lot of time in these maps, so speedups here will yield a lot of benefit.  Look at the heavy hitters from the profile, stare at the Core code and see if it’s s good as it can be.

For example, Sebastian discovered a strange infelicity in IntMap.lookup, which I’ve documented in a new ticket

https://gitlab.haskell.org/ghc/ghc/-/issues/20069

I think it’d also be worth measuring how unbalanced our IntMap trees get.  See

https://gitlab.haskell.org/ghc/ghc/-/issues/19820

The speculation there is that we are getting very unbalanced trees.  So measure it!  If it’s true, we could improve matters by using a different IntMap; or maybe by scrambling the key a bit --- see the ticket.

Simon

From: ghc-devs <ghc-devs-bounces@haskell.org> On Behalf Of Young, Jeff
Sent: 02 July 2021 02:36
To: ghc-devs@haskell.org
Subject: Trying to speedup GHC compile times...Help!

Hi ghc devs,

I'm a long-time Haskeller but am just getting into GHC development. I started a 12 week internship at Tweag I/O under Richard Eisenberg this week with the singular goal to speedup GHC compile times. I'm specifically looking to contribute to ghc issues 18541 and 18535. So I thought I would reach out to the community to get some direction on issues/features/problems to tackle in the pursuit of faster compilation times. This is a full time internship and so I think there is a real opportunity to nail down a deliverable for the community, but I want to get some guidance from the experts (you fine people!) before going down a rabbit hole.

To be specific I'm looking for lingering items such as:

  1. It would be great if we had <thing-here> but no one has time.

  2. Primop foo is half complete but is the right type for <common-use-case-which-is-currently-just-a-list>.

  3. Swap <some-type> to an array-like type non-incrementally, that is, establish a patch that rips out the previous type and replaces it with the array-like across the entire compiler, rather than module-by-module.

Point 2 is a specific reference to MR 3571 but I'm unsure of the status and etiquette around MRs, and I'm unsure exactly how fulfilling the todos at the end of that MR would aid in faster compilation times (and if there is evidence to that effect somewhere).

Thanks for the help!

- Jeff