#5224: Improve consistency checking for family instances
---------------------------------+------------------------------------------
    Reporter:  simonpj           |        Owner:              
        Type:  bug               |       Status:  new         
    Priority:  normal            |    Milestone:  7.2.1       
   Component:  Compiler          |      Version:  7.0.3       
    Keywords:                    |     Testcase:              
   Blockedby:                    |   Difficulty:              
          Os:  Unknown/Multiple  |     Blocking:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------
 Several compiler-performance tests got worse when I added the new generic
 default methods (with Pedro):
  * `T3064`: peak_megabytes_allocated 24 is more than maximum allowed 16
  * `IndTypesPerf`: needs more than the 20M heap it is given
  * `T4801`: max_bytes_used 31.4M is more than maximum allowed 30M

 For the first two of these we know exactly why: the (necessarily) eager
 overlap check is reading interface files that are otherwise not read,
 becuase of the new `Rep` type family instances in `Data.Maybe` and so on.
 Both these tests use type families.

 For T4801 it's more mysterious.  The test does not use type families, and
 no new interface files are read, but residency increases.  So the cause
 may be different.

 I'm pretty sure we can improve matters by propagating a bit more info;
 specifically, rather than a module simply saying "I have some type
 familily instances" it can say "I have type family instances for F, G, H".

 I have marked the three tests as expect-broken for now, with the ticket to
 remind me to get back to it.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5224>
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