<div dir="auto"><div>Nod nod.</div><div dir="auto"><br></div><div dir="auto">amazonka-ec2 has a particularly painful module containing just a couple of hundred type definitions and associated instances and stuff. None of the types is enormous. There's an issue open on GitHub[1] where I've guessed at some possible better ways of splitting the types up to make GHC's life easier, but it'd be great if it didn't need any such shenanigans. It's a bit of a pathological case: auto-generated 15kLoC and lots of deriving, but I still feel it should be possible to compile with less than 2.8GB RSS.</div><div dir="auto"> <br><div class="gmail_extra" dir="auto">[1] <a href="https://github.com/brendanhay/amazonka/issues/304">https://github.com/brendanhay/amazonka/issues/304</a></div><div class="gmail_extra" dir="auto"><br></div><div class="gmail_extra" dir="auto">Cheers,</div><div class="gmail_extra" dir="auto"><br></div><div class="gmail_extra" dir="auto">David</div><div class="gmail_extra" dir="auto"><br><div class="gmail_quote" dir="auto">On 4 Dec 2016 19:51, "Alan & Kim Zimmerman" <<a href="mailto:alan.zimm@gmail.com">alan.zimm@gmail.com</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>I agree.<br><br></div>I find compilation time on things with large data structures, such as working with the GHC AST via the GHC API get pretty slow.<br><br></div>To the point where I have had to explicitly disable optimisation on HaRe, otherwise the build takes too long.<br><br></div>Alan<br><br></div><div class="gmail_extra"><br><div class="gmail_quote"><div class="elided-text">On Sun, Dec 4, 2016 at 9:47 PM, Michal Terepeta <span dir="ltr"><<a href="mailto:michal.terepeta@gmail.com" target="_blank">michal.terepeta@gmail.com</a>></span> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="elided-text"><div dir="ltr"><div><div><div>Hi everyone,</div><div><br></div><div>I've been running nofib a few times recently to see the effect of some changes</div><div>on compile time (not the runtime of the compiled program). And I've started</div><div>wondering how representative nofib is when it comes to measuring compile time</div><div>and compiler allocations? It seems that most of the nofib programs compile</div><div>really quickly...</div><div><br></div><div>Is there some collections of modules/libraries/applications that were put</div><div>together with the purpose of benchmarking GHC itself and I just haven't</div><div>seen/found it?</div><div><br></div><div>If not, maybe we should create something? IMHO it sounds reasonable to have</div><div>separate benchmarks for:</div><div>- Performance of GHC itself.</div><div>- Performance of the code generated by GHC.</div><div><br></div><div>Thanks,</div><div>Michal</div></div></div><div><br></div></div>
<br></div>______________________________<wbr>_________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bi<wbr>n/mailman/listinfo/ghc-devs</a><br>
<br></blockquote></div><br></div>
<br>______________________________<wbr>_________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/ghc-devs</a><br>
<br></blockquote></div><br></div></div></div>