Hi, I suggest following variants for solving INLINE containers issues. This solution will be short-term only, the long-term one will probably go in the way of being able to specialize INLINABLE functions. a) remove all INLINEs - smallest code - up to 50% worse - the numbers are in one of my previous mail b) leave all INLINEs - biggest code - fastest - numbers are in one of my previous mail c) remove all INLINEs, but leave small amount of reasonable INLINEs - on functions needing Ord, ie. Map and Set - on 'small' functions only -- member, notMember, lookup*, insert*, delete*, alter*, update*, adjust* and fold* - set balance, balanceL and balanceR as NOINLINE (otherwise they get inlined in insert*, making them too big) - smaller code bloat - ghc binary is 1.4% larger than a) instead of 3.8% (which is the amount b) is larger than a)) - map-properties test is 0.4% larger instead of 126% - Map benchmark is actually 0.2% smaller (probably because of balanceL and balanceR not inlining to insert) - reasonable performance. Here is the speedup of c) against b), measured in % (+= several pct). alter 2.73 delete 3.01 difference 3.76 insert -16.40 insertLookupWithKey empty -1.60 insertLookupWithKey update -2.32 insertLookupWithKey' empty -8.39 insertLookupWithKey' update -15.75 insertWith empty -16.04 insertWith update -15.26 insertWith' empty -17.13 insertWith' update -14.67 insertWithKey empty -15.35 insertWithKey update -13.01 insertWithKey' empty -17.09 insertWithKey' update -16.81 intersection -3.46 lookup 2.73 lookupIndex 0.52 union 0.66 update 3.28 updateLookupWithKey -1.44 The only penalty is 15% loss on insert because of not inlining balanceL and balanceR. But when doing so, the bloat is nearly as in b). I vote for c) and have the patches ready. If there are no major objections, I will push the patches in several hours. (or should I do it sooner? Ian? Simon?) Milan