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