Solving the containers INLINE issue
fox at ucw.cz
Fri Sep 24 07:00:19 EDT 2010
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
- 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).
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
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?)
More information about the Libraries