fox:
Hi,
we still need to find consensus on containers INLINE issue (sorry about me already deciding and pushing :().
To recapitulate, one part of the containers performance improvements was to put INLINE on nearly all Data.Map methods. That has positive impact on performance (especially for Map Int, Map Word, Map Char, etc, where the comparison is just an instruction; for fold method the speedup works for almost any type). The reason for this is that inlining allows specialization to happen.
The negative effect is that the code for insert, lookup, etc. is repeated on every call site. That is not very reasonable (code bloat, I-cache misses).
In the long run we could have something like 'SPECIALISABLE' pragma, which would work like c++ template specialization -- every specialization of a method would be only once in the resulting binary. That would have both speed and reasonably small code bloat.
GHC 7.0 supports INLINABLE -- the method unfolding is present in the .hi file and GHC decides whether to inline or not.
In the short run we need to choose some kind of compromise. What are the possibilities:
a) we remove all INLINE and will mark every method INLINABLE. This keeps smallest code, but if someone needs great performance, they can persuade GHC-7.0 inliner to inline the methods from containers.
b) we leave INLINE on small amount of small methods where there is a big gain, and mark the rest as INLINABLE.
This is what is currently present in the repo (what I pushed without consensus).
This is a compromise, some code bloat, small performance losses. The performance gains are present also on ghc-6.* family (not true with a).
c) leave all methods marked INLINE. Biggest code bloat (numbers in some of my previous mails), theoretically biggest performance (theoretically I-cache misses could be larger).
I think b) is good in the short run, but it is only my opinion. But a) is good idea too and I would also support it.
I am flying to ICFP in an hour. I will investigate a) [what switches to give to GHC-7.0 to inline] and post the results, but it will take some time.
There's no rush, and we can discuss it all at ICFP :-) -- Don