<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hey,<div><br></div><div>when going through Simon-nofib-notes, I stumbled over this thread from March 2017, when I hadn't yet subscribed to this list: <a href="https://mail.haskell.org/pipermail/ghc-devs/2017-March/013887.html">https://mail.haskell.org/pipermail/ghc-devs/2017-March/013887.html</a>.</div><div>Joachim and Simon were trying to pin-point seemingly random regressions and improvements of ~5% to `binary-trees`.</div><div>It's hard to say in retrospect, but I suspect this is the same effect I experienced in #15333 and I'm about to fix in #15999, e.g. that small changes to allocations lead to big, uncorrelated jumps in runtime performance due to GC.</div><div><br></div><div>Just wanted to record this here for posterity.</div><div><br></div><div>Cheers<br>Sebastian</div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><pre>Hi,

Am Dienstag, den 07.03.2017, 22:55 +0000 schrieb Simon Peyton Jones via
ghc-devs:
><i> > But: binary-trees runtime increases by 5%.
</i>><i> 
</i>><i> David: might you look to see if there is any obvious reason for this
</i>><i> regression?  We could just accept it, but it's always good to know
</i>><i> why, and to document it.
</i>
Turns out that my commit
Add rule mapFB c (λx.x) = c
fixed that regression:
<a href="https://perf.haskell.org/ghc/#revision/2fa44217c1d9722227297eefb0d6c6aed7e128ca">https://perf.haskell.org/ghc/#revision/2fa44217c1d9722227297eefb0d6c6aed7e128ca</a>

Maybe there is just a performance cliff there, and these jumps don’t
really mean anything.

Greetings,
Joachim</pre></blockquote></div></div></div></div></div>