I'm actually not sure that the effect on compiler performance is all
#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 lukemaurer): Replying to [comment:2 bgamari]: that modest, unfortunately. [[https://perf.haskell.org/ghc/#revision/8d5cf8bf584fd4849917c29d82dcf46ee75dd035|Gipeda]] shows that the build time for GHC itself went up by 13%. While some increase is to be expected, this is quite significant. Are there any obvious knobs that could be adjusted to reduce the amount of work that the join point analysis/simplifier do under `-O1`? The full analysis is great for `-O2`, but I do fear that users will be up in arms if the GHC regression is representative of user code. There isn't anything obvious—the occurrence analyser looks for join points as it goes, and that process should only be a small constant overhead. Nothing in the simplifier (or elsewhere that I can think of) has to work particularly hard to handle join points (or it shouldn't, anyway!).
Also, strangely enough, while the join points work eliminated all allocations from `fannkuch-redux`, the actual runtime of this test might have actually gone up by 8%. I say "might have" since runtime measurements are notoriously unstable, but it does look likely that this is a real regression: the test's runtime is quite long (4 seconds) and 8% is quite a large change. Even if this measurement were off by a factor of two we would want to understand it. Can you shed any light on this, Luke?
I haven't seen that jump before, and it's not obvious why it would happen. A quick diff of the dumps shows that the two versions end up with wildly different code, so it may be hard to pin any particular culprit. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13220#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler