#13220: Performance regressions in testsuite from join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: bug | Status: new Priority: highest | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): An initial report. I collected timing information from validation builds of the "Join points" commit and its parent commit, each built twice using ghc-8.0.2 and then a perf build of the same commit as the bootstrapping compiler (for reasons to become clear below). I have only looked at the timing results for a few modules so far. Here are the times for everyone's favorite module, `DynFlags.hs`. {{{ stage1 build: bootstrapped by mutator CPU seconds ghc-8.0.2 63s ghc-HEAD-before-join 63s ghc-HEAD-after-join 67s stage2 build: ghc-HEAD-before-join 150-154s ghc-HEAD-after-join 209-213s }}} Observations: * Performance of the perf build (used as the bootstrapping compiler, for the stage1 build of `DynFlags`) may have regressed by a few percent with join points. For now this is looking at the time for just one module, so I wouldn't take that number very seriously. * The time it took the stage1 compiler to perform the stage2 build of `DynFlags` increased by around 40% with the join point change. But, these numbers are both MUCH larger than the time it took to do the stage1 build of `DynFlags`. There are a few possible causes: - The stage1 compiler is built with only `-O`, unlike the perf build that produced the bootstrapping compiler, which built with `-O2`. - The stage1 compiler is built with `-DDEBUG`, so it contains extra sanity checks. - The stage2 compiler is built with `-dcore-lint`, so additional extra checks are being done during the stage2 build. - Something else about the build could be different between the two stages, like the values of CPP macros. I think this is unlikely to be the cause in this case. One of these points seems to have gotten much worse with join points. The good news is that, according to preliminary results, the performance of the perf (i.e., release) build of the compiler seems to be minimally affected. And if the performance regression is in `-dcore-lint`, for example, it may be easy to track down and eliminate. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13220#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler