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