<div class="gmail_quote">On Thu, Sep 23, 2010 at 12:40 PM, Simon Marlow <span dir="ltr"><<a href="mailto:marlowsd@gmail.com">marlowsd@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
For those who didn't follow this discussion on cvs-ghc: since the Data.Map/IntMap patches went into the repo (for testing and experimentation), we noticed some code blowup due to the extra INLINEs. e.g. one module in GHC that makes heavy use of Data.Map tripled in size from 150k to 450k:<br>
<br>
<a href="http://www.haskell.org/pipermail/cvs-ghc/2010-September/055944.html" target="_blank">http://www.haskell.org/pipermail/cvs-ghc/2010-September/055944.html</a><br>
<br>
we came up with a possible solution: a pragma that exports an inlining but doesn't force the unfolding to take place in all client code. Basically it defers the decision about whether to inline to the call site, which is the right thing: GHC's inlining heuristics are quite well-tuned to balance performance benefit against code blowup, and the client can always turn up the knob with -funfolding-use-threshold100 if they wish. So in GHC 7.0 you can say<br>
<br>
{-# INLINABLE f #-}<br>
<br>
to get the new behaviour. Of course this isn't backwards-compatible: the pragma will be ignored by older GHCs, so you might want to use some CPP trickery.<br>
<br>
So what to do for GHC 7.0. The options are:<br>
<br>
- make the INLINABLE changes, re-do the measurements to make sure<br>
performance hasn't got worse, and push the patches.<br></blockquote><div><br>I prefer this option.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I have no strong opinions, but we have to do something soon: the GHC 7.0 RC is due out tomorrow. I be happy to make the INLINABLE changes myself and test that the code blowup problem is fixed, but I can't do the performance measurements easily. The same applies to Data.Set/IntSet of course.<br>
</blockquote></div><br>You should be able to run the benchmarks quite easily. The instructions are in the benchmark file itself. Just take a quick glance at the execution time mean for a few important function (e.g. insert, delete, lookup, foldl) and make sure things aren't sufficiently worse. If you get the INLINABLE changes into the containers repo I can try to run the benchmarks myself (but it will have to wait until after ICFP).<br>
<br>-- Johan<br><br>