[GHC] #12357: Increasing maximum constraint tuple size significantly blows up compiler allocations
GHC
ghc-devs at haskell.org
Fri Jul 1 19:42:09 UTC 2016
#12357: Increasing maximum constraint tuple size significantly blows up compiler
allocations
-------------------------------------+-------------------------------------
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: Compile-time | Unknown/Multiple
performance bug | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s):
Wiki Page: |
-------------------------------------+-------------------------------------
Description changed by bgamari:
@@ -7,0 +7,5 @@
+
+ Judging by ticky and the cost-center profiler the performance regression
+ appears to simply be the result of the loading the new declarations from
+ the interface file, as one might expect. Nevertheless, it's quite silly to
+ pay such a large price for a change that only gets occasionally exercised.
New description:
In July 2015 (dd3080fe0263082f65bf2570f49189c277b12e28) the maximum
constraint tuple size was raised from 16 to 62 to address #10451. It turns
out that this change is apparently one of the larger compile-time
regressions in recent GHC history. For instance, the nofib
`real/fulsom/Shapes.hs` module regresses by around 15% in both compiler
allocations and compile time.
Judging by ticky and the cost-center profiler the performance regression
appears to simply be the result of the loading the new declarations from
the interface file, as one might expect. Nevertheless, it's quite silly to
pay such a large price for a change that only gets occasionally exercised.
--
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12357#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list