#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/54b9b064fc7960a4dbad387481bc3a6496cc39... (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