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

[GHC]

#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):

 There is currently a GHC flag which controls whether `build` desugaring is
 used at all, `-fsimple-list-literals`. To roughly characterize the effect
 of `build` on allocation, I did a nofib against
 3f60ce8751c860a2bd0ddbe87429136a9d97449b run with and without `-fsimple-
 list-literals`. The major allocation changes were,
 {{{
 --------------------------------------------------------------------------------
         Program           Size    Allocs   Runtime   Elapsed  TotalMem
 --------------------------------------------------------------------------------
            ansi          +0.0%    +10.8%     0.000     0.004      0.0%
            bspt          +0.1%     +2.7%     0.004     0.004      0.0%
       cacheprof          +0.1%     +3.3%     0.181     0.181      0.0%
           eliza          -0.2%     +0.8%     0.000     0.000      0.0%
           fluid          -0.1%     +0.7%     0.004     0.004      0.0%
          fulsom          +0.0%     +0.7%     0.125     0.125    -21.4%
       integrate          +0.0%   +152.6%     0.081     0.081     +7.4%
            lift          +0.0%     +4.5%     0.000     0.000      0.0%
        nucleic2          -0.3%     +2.4%     0.024     0.024      0.0%
          parser          -0.4%     +0.6%     0.011     0.012      0.0%
         reptile          -0.0%     +0.1%     0.004     0.004      0.0%
         rewrite          +0.1%    +96.7%     0.007     0.012      0.0%
 (those tests with no change in allocations omitted)
 --------------------------------------------------------------------------------
             Min          -0.4%     -0.2%     -1.0%     -2.0%    -21.4%
             Max          +0.1%   +152.6%     +0.3%     +0.6%     +7.4%
  Geometric Mean          -0.0%     +1.9%     -0.2%     -0.2%     -0.2%
 }}}

 There are a few things to note here:

  * Allocations, if they change at all, increase without `build` fusion, as
 we would expect
  * A `fulsom` had its total memory usage dramatically reduced without
 `build` fusion; this may be worth further investigation.
  * Runtime didn't appreciably change in any case
  * Binary sizes don't change

 On the other hand, if I compile `T9961` with `-fsimple-list-literals`, I
 see a dramatic reduction in compiler allocations (from 745044392 to
 518841472, about 30%). Unfortunately it's not easy to measure the runtime
 cost of list construction with this test. I'll try to write up a simple
 `Criterion` benchmark
 to do this.

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