Containers INLINE issue continues

[Johan Tibell]

On Sat, Sep 25, 2010 at 7:17 AM, Milan Straka <fox at ucw.cz> wrote:
> 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.

Lets add benchmarks for Map Integer, Map String, and Map ByteString so
we can quantify the difference in performance gains from

* cheap vs expensive comparison, and
* boxed vs unboxed keys.

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

Once we have this pragma we could play some tricks with the linker to
share specializations across modules e.g. if insert is specialized at
Int in two modules, they could share the same code.

I believe that the higher order functions, like fold, will always have
to be INLINE (or INLINABLE) as the performance gain there comes from
making the higher order parameter known, something specialization
won't do.

-- Johan