Should folds in containers package remain INLINE

[Johan Tibell]

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 gmail.com> 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 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
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries