Solving the containers INLINE issue
marlowsd at gmail.com
Fri Sep 24 07:51:02 EDT 2010
On 24/09/2010 12:00, Milan Straka wrote:
> 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.
I suggest a slight modification of (c): for the functions on which you
removed the INLINE pragmas, put INLINABLE on them. This way a client
can still get the full speedup with suitable flags if they want.
I'm still not really keen on having lookup inlined at every single call
site, but I know it's a tradeoff and other people (maybe most people)
care less about code size than I do.
> If there are no major objections, I will push the patches in several hours.
> (or should I do it sooner? Ian? Simon?)
> Libraries mailing list
> Libraries at haskell.org
More information about the Libraries