[GHC] #3064: Very long compile times with type functions
GHC
ghc-devs at haskell.org
Fri Oct 21 16:16:17 UTC 2016
#3064: Very long compile times with type functions
-------------------------------------+-------------------------------------
Reporter: simonpj | Owner:
Type: bug | Status: closed
Priority: low | Milestone: 8.0.1
Component: Compiler (Type | Version: 6.10.1
checker) |
Resolution: fixed | Keywords:
Operating System: Unknown/Multiple | Architecture:
| Unknown/Multiple
Type of failure: Compile-time | Test Case:
performance bug | perf/compiler/T3064
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s):
-------------------------------------+-------------------------------------
Comment (by Simon Peyton Jones <simonpj@…>):
In [changeset:"1f09b246d377a0007a953e5a77545d81671d2e36/ghc"
1f09b246/ghc]:
{{{
#!CommitTicketReference repository="ghc"
revision="1f09b246d377a0007a953e5a77545d81671d2e36"
Accept 20% dedgradation in Trac #5030 compile time
In commit
31621b12 * A collection of type-inference refactorings.
I fixed a bug in the on-the-fly unifier. Usually the
on-the-fly unifier (TcUnify) defers type function
applications to the constraint solver. But in one situation
it inconsistently did not defer, so a unification happened
without reducing a type function. By a fluke this makes
T5030 (specifcially the definition of cnst) much better.
It turns out that consistently non-deferring type functions
makes the test for #3064 go bad. So somehow the current,
inconsistent situation was an accidental sweet spot.
But it's a horrible sweet spot, relying on what was essentially
a bug. So I've accepted the worsening (it's an exotic case),
and opened #12724 to deal with the underlying cause.
}}}
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3064#comment:24>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list