Solving the containers INLINE issue

[Milan Straka]

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