#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