Should folds in containers package remain INLINE
fox at ucw.cz
Thu Apr 26 13:10:24 CEST 2012
this came up when discussing increasing size of GHC binary.
Currently all folds in containers package are marked as INLINE. This has
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
Simon Marlow suggested that folds could be marked INLINABLE. Then they
would probably not be inlined automatically, but one could say
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