#5030: Slow type checking of type-level computation heavy code.
-------------------------------------------+--------------------------------
  Reporter:  thesz                         |          Owner:         
      Type:  bug                           |         Status:  new    
  Priority:  normal                        |      Milestone:  7.2.1  
 Component:  Compiler (Type checker)       |        Version:  7.0.2  
Resolution:                                |       Keywords:         
        Os:  Unknown/Multiple              |   Architecture:  x86    
   Failure:  Compile-time performance bug  |     Difficulty:  Unknown
  Testcase:  T5030                         |      Blockedby:         
  Blocking:                                |        Related:         
-------------------------------------------+--------------------------------
Changes (by simonpj):

  * owner:  igloo =>
  * difficulty:  => Unknown
  * status:  closed => new
  * resolution:  fixed =>


Comment:

 I'm re-opening following a refactoring in the constraint solver.
 {{{
 commit dd7522c3b14bce1af94bffd61c4d38e670f53495
 Author: Simon Peyton Jones <[email protected]>
 Date:   Mon May 7 17:40:34 2012 +0100

     Yet another major refactoring of the constraint solver

     This is the result of Simon and Dimitrios doing a code walk through.
     There is no change in behaviour, but the structure is much better.
     Main changes:

     * Given constraints contain an EvTerm not an EvVar

     * Correspondingly, TcEvidence is a recursive types that uses
       EvTerms rather than EvVars

     * Rename CtFlavor to CtEvidence

     * Every CtEvidence has a ctev_pred field.  And use record fields
       consistently for CtEvidence

     * The solved-constraint fields of InertSet (namely inert_solved and
       inert_solved_funeqs) contain CtEvidence, not Ct

     There is a long cascade of follow-on changes.
 }}}
 Generally speaking this refactoring is a win, but it makes this particular
 test get worse:
 {{{
 Baseline:             391M allocated
 With this change:     479M allocated
 }}}
 I'm sure it's not a big deal to fix, but I'm going to re-open the ticket
 so that Dimitrios and I look at it again.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5030#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler

_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Reply via email to