[GHC] #13220: Performance regressions in testsuite from join points

[GHC]

#13220: Performance regressions in testsuite from join points
-------------------------------------+-------------------------------------
        Reporter:  lukemaurer        |                Owner:  rwbarton
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:  8.2.1
       Component:  Compiler          |              Version:  8.1
      Resolution:                    |             Keywords:  JoinPoints
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):  Phab:3391
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Changes (by rwbarton):

 * priority:  highest => normal


Comment:

 The other regressions are small (~5%) and the join points commit is so
 complicated and so long ago that I doubt looking at these changes is the
 easiest way to gain a few percent on a few benchmarks.

 Furthermore the issue is clouded by indirect effects of the join points
 change that result from running a stage2 compiler. For example parsing and
 typechecking allocates slightly less after join points, but these gains
 are roughly canceled out by increased allocations during desugaring. Since
 these phases were presumably not changed by the join points commit, this
 changes must be due to different code generation with join points. These
 changes are probably more interesting than slight changes in perf tests.

 In all three `perf/compiler` tests where allocations changed, there were
 no significant changes to Core program size. It looks like the simplifier
 is just doing more work, which is no big surprise. I looked at T9020 (the
 simplest test case) with stage1 compilers built with ticky, but the code
 changes are extensive enough that I couldn't draw any conclusion from the
 results (many changes, new functions added, and old functions removed).

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