Should folds in containers package remain INLINE

Milan Straka fox at
Thu Apr 26 13:10:24 CEST 2012

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?


More information about the Libraries mailing list