<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">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><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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>______________________________<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>