[GHC] #13227: Loss of full laziness in mapFB

[GHC]

#13227: Loss of full laziness in mapFB
-------------------------------------+-------------------------------------
        Reporter:  simonpj           |                Owner:  nomeata
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.0.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):  Phab:D3067
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by nomeata):

 Results are back:
 https://perf.haskell.org/ghc/#compare/54b9b064fc7960a4dbad387481bc3a6496cc397f/88dcbc63ae3482c55e96c12ab02ebc9a820781ff
 (not sure how stable that link is given that this is a rebasing branch)

 With only adding `length (takeWhile isOneShotInfo (occ_one_shots env))`,
 nofib allocations are stable. This suggests that this is a sane thing to
 do, i.e. we do not duplicate any work.

 Binary sizes go down by -0.7% throughout the bank, so there is relevant
 effect.

 We get a run-time performance loss in `binary-trees` by 9%. `binary-trees`
 benefited strongly from Join Point, so my blind guess is that in some
 instance here, floating out is beneficial as it turned something into a
 join point.

 Morally, the code is what we want (it makes the analysis more precise). I
 guess we should check out the performance fall out in `binary-tree`,
 though…

 You can have a look at the code at Phab:D3089.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13227#comment:15>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler