[GHC] #11707: Don't desugar large lists with build

GHC ghc-devs at haskell.org
Tue Mar 15 12:52:08 UTC 2016


#11707: Don't desugar large lists with build
-------------------------------------+-------------------------------------
        Reporter:  bgamari           |                Owner:
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  7.10.3
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Runtime           |  Unknown/Multiple
  performance bug                    |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by bgamari):

 I've pushed a simple approach to avoid `build`-based list desugaring for
 large lists to Phab:D2007. Here we simply threshold on the list length. I
 have a few concerns about this approach,

  * This threshold introduces a "performance cliff", where users will
 suddenly see drastically different performance characteristics as their
 literal lists grow.
  * There isn't really a good way to choose this size. Ideally we'd want a
 smaller threshold with larger consumers and vice-versa, but we have no way
 of knowing what will be consuming our list in the desugaring.

  From a runtime performance perspective, applying `build` more liberally
 should rarely hurt (it can only expose further optimization opportunities;
 if no fusion is possible it will eventually get rule-rewritten back to a
 list)

  Consequently, the threshold we introduce here is a bit concerning since
 we are limiting contexts in which we'll use `build`, potentially hiding
 optimizations.

 Regardless, `nofib` shows no change in allocations after this change, so
 it at very least doesn't hurt any of the cases there. Moreover, it shows a
 30% reduction in compiler allocations in `T9961` (from 745044392 to
 745044392 bytes).

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


More information about the ghc-tickets mailing list