<div dir="ltr"><div>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.</div><div><br></div><div>Let us know how it goes for you.</div><div><br></div><div>Cheers,</div><div><br></div><div>Matt<br></div><div><br></div><div><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, Jan 17, 2025 at 11:30 AM ÉRDI Gergő <<a href="mailto:gergo@erdi.hu">gergo@erdi.hu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, 17 Jan 2025, Matthew Pickering wrote:<br>
<br>
> 1. As Zubin points out we have recently been concerned with improving the memory usage<br>
> of large module sessions (#25511, !13675, !13593)<br>
> <br>
> I imagine all these patches will greatly help the memory usage in your use case.<br>
<br>
I'll try these out and report back.<br>
<br>
> 2. You are absolutely right that ModDetails can get forced and is never reset.<br>
> <br>
> If you try !13675, it should be much more easily possible to reset the ModDetails by<br>
> writing into the IORef which stores each home package.<br>
<br>
Yes, that makes sense.<br>
<br>
> 3. If you share your example or perhaps even a trace from ghc-debug then I will be<br>
> happy to investigate further as it seems like a great test case for the work we have<br>
> recently been doing.<br>
<br>
Untangling just the parts that exercise the GHC API from all the other <br>
in-house bits will be quite a lot of work. But if just a ghc-debug <br>
snapshot of e.g. a small example from scratch  vs. from existing ModIfaces <br>
would be helpful (with e.g. the top HscEnv at the time of finishing all <br>
typechecking as a saved closure), I can provide that no prob.<br>
<br>
Thanks,<br>
        Gergo<br>
</blockquote></div>