Data.Foldable causes missed foldr/build opportunities

[Edward Kmett]

One of the open concerns about it is definitely ensuring that we get the
fusion opportunities we can.

If you put an INLINE pragma on your Foldable version of each do the fusion
rules fire after it gets inlined into a call site that uses it as a list?

-Edward

On Thu, Jul 25, 2013 at 1:22 PM, Gabriel Gonzalez <gabriel439 at gmail.com>wrote:

> I'm now in favor of the `Data.Foldable` proposal, but I just wanted to
> mention that the proposal needs to include some extra pragma work to ensure
> that build/foldr optimizations fire.  I was just experimenting with the
> following combinator for `pipes` trying out the following two versions:
>
>     each :: (Monad m) => [a] -> Producer a m ()
>     each = mapM yield
>
>     each :: (Monad m, Foldable f) => f a -> Producer a m ()
>     each = Data.Foldable.mapM yield
>
> When I do a pure `pipes`-based fold over both `Producers`s, the version
> specialized to lists triggers a firing of the build/foldr fusion rule and
> runs about 20% faster.  The true improvement for `mapM` by itself is
> probably even greater than that because I haven't optimized the folding
> code yet.  The latter version does not trigger the rule firing.  Either way
> I'm going to include the latter `Foldable` version but I just wanted to
> mention this because I remember people were asking if this would impact
> fusion or not.
>
> ______________________________**_________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/**mailman/listinfo/libraries<http://www.haskell.org/mailman/listinfo/libraries>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20130725/46cbdd3a/attachment.htm>