Should folds in containers package remain INLINE

[Ryan Newton]

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 ucw.cz> 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 haskell.org
> http://www.haskell.org/mailman/listinfo/libraries