<div dir="ltr">Hello,<div><br></div><div>Apologies upfront for the long post below, but I thought our experience on this particular point might be worth sharing. I present some observations first and then mention the particular problem around "cabal repl" facilitated development workflow. Any ideas/feedback on the latter point would be much appreciated and please let me know if there are other metrics, info or output I can produce here for further investigation/clarification. </div><div><br></div><div><div>Recently at work, we upgraded a decent size project from GHC 7.6.3 to GHC 7.8.4 and as a result observed a very significant slowdown in compile times. Code changes were very minimal and should not be a factor. Any mistakes below are mine, but I can fairly confidently say that there is a visible-to-the-eye slowdown in compile times.<br></div><div></div><div><br></div><div>We made a few measurements to quantify the issue and here is the data:</div><div><ul><li>This project has 220 direct modules (non-dependency) that are compiled with each "cabal build" and we always use sandboxes</li><li>Tests were performed on OS X, though we saw similar results on Linux</li><li>Single threaded (-j=1) wall-clock compile time has gone up by around 30% for the overall project</li><li>With O1 and -j=N, the overall wall-clock time is approximately the same (around 8 min), but the CPU time spent is a staggering 7.5X higher (!)</li><li>With O0 and -j=N the overall wall-clock time is 40% higher, but the CPU time spent is a staggering 7.5X higher (!)</li><li>With -O0, "cabal repl" load times have gone up by a staggering 2.5X (!)</li><ul><li>7.8.4: 3 min. 35 seconds</li><li>7.6.3: 1 min. 2 seconds</li></ul><li>Measuring compile times for individual modules, we see that those that are heavily loaded with lots of types, TH-facilitated type and typeclass derivations and those that contain large "blobs" of values directly at the top level now take much longer to compile:</li><ul><li>We have 10 modules that each take over 10 seconds</li><li>We have 3 modules that each take over 35 seconds</li></ul><li>Sidenote observation: In general, parallel builds with -j appear to cause a very significant overhead under the "system" part of timing:</li><ul><li>Example with 7.6.3, O0: cabal build  140.57s user 13.25s system 100% cpu 2:33.70 total</li><li>Example with 7.8.4, O0: cabal build  507.83s user 655.43s system 549% cpu 3:31.59 total</li></ul></ul><div><br></div><div>The main hurt here has been the infeasibility of using "cabal repl / ghci"  fast-feedback style development (via emacs, vim, command-line, etc.), since:</div><div><ul><li>Unlike "cabal build", "cabal repl" re-compiles from scratch with every invocation ":l App.Foo.Bar", which itself is the necessary first step when starting to hack on a module (we can then use :r to somewhat help the situation)</li><li>The slowdown is about 2.5X as stated above: What used to take a minute now takes 3.5 minutes.</li><li>cabal repl does not seem to benefit from -j at all</li><li>cabal repl 7.8.4 appears to be hurt particularly by the heavier modules</li><li>The heavier modules are often at the top of the compile tree (types, derivations, etc) and are practically loaded on the critical path all the time</li></ul></div><div>Let me know if I'm missing anything here and any/all feedback is much appreciated!</div><div><br></div>Cheers,<br>Oz</div></div></div>