GHC memory usage when typechecking from source vs. loading ModIfaces

Matthew Pickering matthewtpickering at gmail.com
Tue Jan 21 12:24:19 UTC 2025


Thanks Gergo, I think that unless we have access to your code base or a
realistic example then the before vs after snapshot will not be so helpful.
It's known that `ModDetails` will leak space like this.

Let us know how it goes for you.

Cheers,

Matt



On Fri, Jan 17, 2025 at 11:30 AM ÉRDI Gergő <gergo at erdi.hu> wrote:

> On Fri, 17 Jan 2025, Matthew Pickering wrote:
>
> > 1. As Zubin points out we have recently been concerned with improving
> the memory usage
> > of large module sessions (#25511, !13675, !13593)
> >
> > I imagine all these patches will greatly help the memory usage in your
> use case.
>
> I'll try these out and report back.
>
> > 2. You are absolutely right that ModDetails can get forced and is never
> reset.
> >
> > If you try !13675, it should be much more easily possible to reset the
> ModDetails by
> > writing into the IORef which stores each home package.
>
> Yes, that makes sense.
>
> > 3. If you share your example or perhaps even a trace from ghc-debug then
> I will be
> > happy to investigate further as it seems like a great test case for the
> work we have
> > recently been doing.
>
> Untangling just the parts that exercise the GHC API from all the other
> in-house bits will be quite a lot of work. But if just a ghc-debug
> snapshot of e.g. a small example from scratch  vs. from existing ModIfaces
> would be helpful (with e.g. the top HscEnv at the time of finishing all
> typechecking as a saved closure), I can provide that no prob.
>
> Thanks,
>         Gergo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20250121/3c429ec1/attachment.html>


More information about the ghc-devs mailing list