<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 7 June 2018 at 22:25, Evan Laforge <span dir="ltr"><<a href="mailto:qdunkan@gmail.com" target="_blank">qdunkan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On Thu, Jun 7, 2018 at 1:47 PM, Simon Marlow <<a href="mailto:marlowsd@gmail.com">marlowsd@gmail.com</a>> wrote:<br>
> For loading large amounts of code into GHCi, you want to add -j<n> +RTS<br>
> -A128m where <n> is the number of cores on your machine. We've found that<br>
> parallel compilation works really well in GHCi provided you use a nice large<br>
> allocation area for the GC. This dramatically speeds up working with large<br>
> numbers of modules in GHCi. (500 is small!)<br>
<br>
</span>This is a bit of a thread hijack (feel free to change the subject),<br>
but I also have a workflow that involves loading a lot of modules in<br>
ghci (500-700).  As long as I can coax ghci to load them, things are<br>
fast and work well, but my impression is that this isn't a common<br>
workflow, and specifically ghc developers don't do this, because just<br>
about every ghc release will break it in one way or another (e.g. by<br>
putting more flags in the recompile check hash), and no one seems to<br>
understand what I'm talking about when I suggest features to improve<br>
it (e.g. the recent msg about modtime and recompilation avoidance).<br>
<br>
Given the uphill battle, I've been thinking that linking most of those<br>
modules into a package and loading much fewer will be a better<br>
supported workflow.  It's actually less convenient, because now it's<br>
divided between package level (which require a restart and relink if<br>
they change) and ghci level (which don't), but is maybe less likely to<br>
be broken by ghc changes.  Also, all those loaded module consume a<br>
huge amount of memory, which I haven't tracked down yet, but maybe<br>
packages will load more efficiently.<br>
<br>
But ideally I would prefer to continue to not use packages, and in<br>
fact do per-module more aggressively for larger codebases, because the<br>
need to restart ghci (or the ghc API-using program) and do a lengthy<br>
relink every time a module in the "wrong place" changed seems like it<br>
could get annoying (in fact it already is, for a cabal-oriented<br>
workflow).<br>
<br>
Does the workflow at Facebook involve loading tons of individual<br>
modules as I do?  </blockquote><div><br></div><div>Yes, our workflow involves loading a large number of modules into GHCi. However, we have run into memory issues, which was the reason for the recent work on fixing this space leak: <a href="https://phabricator.haskell.org/D4659">https://phabricator.haskell.org/D4659</a></div><div><br></div><div>As it is, this workflow is OK thanks to Bartosz' work on speedups for large numbers of modules, tweaking the RTS flags as I mentioned and some other fixes we've made in GHCi to avoid performance issues. (all of this is upstream, incidentally).  There is probably low-hanging fruit to be had in reducing the memory usage of GHCi, nobody has really attacked this with the heap profiler for a while. However, I imagine at some point loading everything into GHCi will become unsustainable and we'll have to explore other strategies. There are a couple of options here:</div><div>- pre-compile modules so that GHCi is loading the .o instead of interpreted code</div><div>- move some of the code into pre-compiled packages, as you mentioned</div></div><div class="gmail_quote"><br></div><div class="gmail_quote">Cheers</div><div class="gmail_quote">Simon</div><div class="gmail_quote"><br></div><div class="gmail_quote"> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Or do they get packed into packages?  If it's the<br>
many modules, do you have recommendations making that work well and<br>
keeping it working?  If packages are the way you're "supposed" to do<br>
things, then is there any idea about how hard it would be to reload<br>
packages at runtime?  If both modules and packages can be reloaded, is<br>
there an intended conceptual difference between a package and an<br>
unpackaged collection of modules?  To illustrate, I would put packages<br>
purely as a way to organize builds and distribution, and have no<br>
meaning at the compiler level, which is how I gather C compilers<br>
traditionally work (e.g. 'cc a.o b.o c.o' is the same as 'ar abc.a a.o<br>
b.o c.o; cc abc.a').  But that's clearly not how ghc sees it!<br>
<br>
<br>
thanks!<br>
</blockquote></div><br></div></div>