<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Dec 5, 2016 at 12:00 PM Moritz Angermann <<a href="mailto:moritz@lichtzwerge.de">moritz@lichtzwerge.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br class="gmail_msg">
<br class="gmail_msg">
I’ve started the GHC Performance Regression Collection Proposal[1] (Rendered [2])<br class="gmail_msg">
a while ago with the idea of having a trivially community curated set of small[3]<br class="gmail_msg">
real-world examples with performance regressions. I might be at fault here for<br class="gmail_msg">
not describing this to the best of my abilities. Thus if there is interested, and<br class="gmail_msg">
this sounds like an useful idea, maybe we should still pursue this proposal?<br class="gmail_msg">
<br class="gmail_msg">
Cheers,<br class="gmail_msg">
 moritz<br class="gmail_msg">
<br class="gmail_msg">
[1]: <a href="https://github.com/ghc-proposals/ghc-proposals/pull/26" rel="noreferrer" class="gmail_msg" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/26</a><br class="gmail_msg">
[2]: <a href="https://github.com/angerman/ghc-proposals/blob/prop/perf-regression/proposals/0000-perf-regression.rst" rel="noreferrer" class="gmail_msg" target="_blank">https://github.com/angerman/ghc-proposals/blob/prop/perf-regression/proposals/0000-perf-regression.rst</a><br class="gmail_msg">
[3]: for some definition of small<br class="gmail_msg"></blockquote><div><br></div><div><div>Interesting! I must have missed this proposal.  It seems that it didn't meet</div><div>with much enthusiasm though (but it also proposes to have a completely separate</div><div>repo on github).</div><div><br></div><div>Personally, I'd be happy with something more modest:</div><div>- A collection of modules/programs that are more representative of real Haskell</div><div>  programs and stress various aspects of the compiler.</div><div>  (this seems to be a weakness of nofib, where >90% of modules compile in less</div><div>  than 0.4s)</div><div>- A way to compile all of those and do "before and after" comparisons easily. To</div><div>  measure the time, we should probably try to compile each module at least a few</div><div>  times.</div><div>  (it seems that this is not currently possible with `tests/perf/compiler` and</div><div>  nofib only compiles the programs once AFAICS)</div><div><br></div><div>Looking at the comments on the proposal from Moritz, most people would prefer to</div><div>extend/improve nofib or `tests/perf/compiler` tests. So I guess the main</div><div>question is - what would be better:</div><div>- Extending nofib with modules that are compile only (i.e., not runnable) and</div><div>  focus on stressing the compiler?</div><div>- Extending `tests/perf/compiler` with ability to run all the tests and do</div><div>  easy "before and after" comparisons?</div><div><br></div><div><div>Personally, I'm slightly leaning towards `tests/perf/compiler` since this would</div><div>allow sharing the same module as a test for `validate` and to be used for</div><div>comparing the performance of the compiler before and after a change.</div></div><div><br></div><div>What do you think?</div><div><br></div><div>Thanks,</div><div>Michal</div></div><div><br></div></div></div>