Proposal: Performance improvements for Data.IntMap

[Johan Tibell]

On Thu, Sep 23, 2010 at 12:40 PM, Simon Marlow <marlowsd at gmail.com> wrote:

> 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:
>
> http://www.haskell.org/pipermail/cvs-ghc/2010-September/055944.html
>
> 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
>
>  {-# INLINABLE f #-}
>
> 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.
>
> So what to do for GHC 7.0.  The options are:
>
>  - make the INLINABLE changes, re-do the measurements to make sure
>   performance hasn't got worse, and push the patches.
>

I prefer this option.


> 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.
>

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).

-- Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/libraries/attachments/20100923/0045259a/attachment.html