Should folds in containers package remain INLINE

Simon Marlow marlowsd at
Wed May 2 13:16:35 CEST 2012

I would like the folds to be INLINABLE.  Rationale:

  - The 0.8% figure is really plucked out of thin air, it depends
    entirely on how many times we call fold.

  - Getting a complete copy of fold each time you call it is overkill.

  - INLINABLE puts the user in control of the performance/size
    tradeoff; with INLINE the user has no control, they always get
    a copy (well, they could write a NOINLINE wrapper, but that's

just MHO...


On 26/04/2012 18:35, Johan Tibell wrote:
> I agree with Ryan, I think we should keep the INLINEs on folds. It's a
> nice property of the current implementation that folds will be as fast
> as handrolled recursive traversals over the data type.
> On Thu, Apr 26, 2012 at 7:22 AM, Ryan Newton<rrnewton at>  wrote:
>> It doesn't seem like enough of a code size reduction to justify the change in this case.
>> Is there any opportunity to attack this problem later in the compiler?  Perhaps a CSE for similar blocks of code?  I've noticed enormous reductions in size using UPX, so I know these binaries themselves are quite compressible.
>> Sent from my cell phone
>> On Apr 26, 2012, at 7:10 AM, Milan Straka<fox at>  wrote:
>>> Hi all,
>>> this came up when discussing increasing size of GHC binary.
>>> Currently all folds in containers package are marked as INLINE. This has
>>> following effects:
>>> 1) the code using folds can be (much) more efficient -- for example, when
>>>    calling statically known function. If the unfolding of that function
>>>    is available, GHC can spot strictness and unbox values -- so
>>>    `foldl (+) (0::Int)` evaluated the sum strictly and without
>>>    allocating space for intermediate Ints.
>>> 2) the resulting binary size increases. If the folds in containers
>>>    package are not INLINEd, the stripped GHC binary shrinks by 303kB,
>>>    which is 0.8% of its size.
>>> Therefore we have speed vs. code size trade-off. FYI, Prelude.foldr is
>>> always inlined, Prelude.foldl is inlined only when GHC thinks it is
>>> worth it.
>>> Simon Marlow suggested that folds could be marked INLINABLE. Then they
>>> would probably not be inlined automatically, but one could say
>>>   inline foldr
>>> to inline the fold on the call sites she chooses.
>>> Personally I am a bit in favor of keeping the folds INLINE. That allows
>>> the users of containers to get best performance without any change to
>>> the code (i.e., adding explicit `inline`). The price to pay is code size
>>> increase, which I consider minor (0.8% for GHC binary).
>>> Any other thoughts?
>>> Cheers,
>>> Milan
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries at
>> _______________________________________________
>> Libraries mailing list
>> Libraries at
> _______________________________________________
> Libraries mailing list
> Libraries at

More information about the Libraries mailing list