Hécate <hecate@glitchbra.in> writes:

> Hello ghc-devs,
>
> I hadn't made significant contributions to the GHC code base in a while,
> until a few days ago, where I discovered that my computer wasn't able to
> sustain running the test suite, nor handle HLS well.
>
> Whether it is my OS automatically killing the process due to oom-killer
> or just the fact that I don't have a war machine, I find it too bad and
> I'm frankly discouraged.

Do you know which process was being killed? There is one testsuite tests
that I know of which does have quite a considerable memory footprint
(T16992) due to its nature; otherwise I would expect a reasonably recent
machine to pass the testsuite without much trouble. It's particularly
concerning if this is a new regression; is this the first time you have
observed this particular failure?

> This is not the first time such feedback emerges, as the documentation
> task force for the base library was unable to properly onboard some
> people from third-world countries who do not have access to hardware
> we'd consider "standard" in western Europe or some parts of North
> America. Or at least "standard" until even my standard stuff didn't cut
> it anymore.
>
> So yeah, I'll stay around but I'm afraid I'm going to have to focus on
> projects for which the feedback loop is not on the scale of hours , as
> this is a hobby project.
>
> Hope this will open some eyes.
>
Hi Hécate,

I would reiterate that the more specific feedback you can offer, the
better.

To share my some of my own experience: I have access to a variety of hardware,
some of which is quite powerful. However, I find that I end up doing
much of my development on my laptop which, while certainly not a slouch
(being a Ryzen 4750U), is also not a monster. In particular, while a
fresh build takes nearly twice as long on my laptop than some of the
other hardware I have, I nevertheless find ways to make it worthwhile
(due to the ease of iteration compared to ssh). If you routinely have
multi-hour iteration times then something isn't right.

In particular, I think there are a few tricks which make life far
easier:


 * Be careful about doing things that would incur
   significant amounts of rebuilding. This includes:

    * After modifying, e.g., `compiler/ghc.cabal.in` (e.g. to add a new
      module to GHC), modify `compiler/ghc.cabal` manually instead of
      rerunning `configure`.

    * Be careful about pulling/rebase. I generally pick a base commit to
      build off of and rebase sparingly: Having to stop what I'm doing to
      wait for full rebuild is an easy way to lose momentum.

    * Avoid switching branches; I generally have a GHC tree per on-going
      project.

 * Take advantage of Hadrian's `--freeze1` flag

 * Use `hadrian/ghci` to typecheck changes

 * Use the stage1 compiler instead of stage2 to smoke-test changes when
   possible. (specifically, using the script generated by Hadrian's
   `_build/ghc-stage1` target)

 * Use the right build flavour for the task at hand: If I don't need a
   performant compiler and am confident that I can get by without
   thorough testsuite validation, I use `quick`. Otherwise, plan ahead
   for what you need (e.g. `default+assertions+debug_info` or
   `validate`)

 * Run the fraction of the testsuite that is relevant to your change.
   Hadrian's `--test-way` and `--only` flags are your friends.

 * Take advantage of CI. At the moment we have a fair amount of CI
   capacity. If you think that your change is close to working, you can
   open an MR and start a build locally. If it fails, iterate on just the
   failing testcases locally.

 * Task-level parallelism. Admittedly, this is harder when you are
   working as a hobby, but I often have two or three projects on-going
   at a time. While one tree is building I try to make progress on
   another.

I don't use HLS so I may be insulated from some of the pain in this
regard. However, I do know that Matt is a regular user and he
disables most plugins.

I would also say that, sadly, GHC is comparable to other similarly-size
compilers in its build time: A build of LLVM (not even clang) takes ~50
minutes on my 8-core desktop; impressively, rustc takes ~7 minutes
although it is a considerably smaller compiler (being just a front-end).
By contrast, GHC takes around 20 minutes. I know that this doesn't
make the cost any easier to bear and I would love to bring this number
down, but ultimately there are only so many hours in the day.

I think one underexplored approach to addressing the build-time problem
is to look not at the full-build time but rather look for common tasks
where we could *avoid* doing a full build (e.g. updating documentation,
typechecking `base`, running a "good enough" subset of the testsuite)
and find ways to make those workflows more efficient.

Cheers,

- Ben

_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs