Re: [GHC] #3064: Very long compile times with type functions
#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
participants (1)
-
GHC