[GHC] #11196: TypeInType performance regressions

[GHC]

#11196: TypeInType performance regressions
-------------------------------------+-------------------------------------
        Reporter:  goldfire          |                Owner:
            Type:  bug               |               Status:  new
        Priority:  highest           |            Milestone:  8.0.1
       Component:  Compiler          |              Version:  7.11
      Resolution:                    |             Keywords:  TypeInType
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Changes (by goldfire):

 * owner:  goldfire =>


Comment:

 I'm afraid I have to declare defeat against this ticket. :(

 I've spent the better part of the last few days trying to understand
 what's going on here, but failed utterly. I simply cannot find the source
 of the slowdown. It just seems like ''everything'' is doing more
 allocation, making it rather hard to find a culprit. I tried putting SCCs
 on low-level functions, too, but to no avail. The one moment of glory was
 finding that `tcMatchTys` was taking up 25% of the allocations on T9872c.
 I identified that the cause was a check to make sure that we don't match
 with a local, forall-bound variable. Of course, local forall-bound
 variables are rare, so I optimized the check by seeing if there are any
 forall-bound variables. This led to a whopping improvement of 20%! But
 then, inexplicably, when I turn off profiling, the exact same optimization
 led to no improvement.

 My tinkering led to a few tiny optimizations, leading to 5% reduction in
 two test cases. This is a small victory, but doesn't really undo the sting
 of defeat. (Optimizations to land in the next day or so.)

 My best guess is that the extra variables due to runtime polymorphism are
 what's gumming up the works. Previously, every binder without a type
 signature (including all local ones) were given a type `alpha ::
 OpenKind`. Now, every binder is given `alpha :: TYPE rho`; two
 metavariables where there was once one. And even when the type is solved,
 the kind now takes up more space than it did previously. But I have no
 data to back this up.

 I'm very happy to advise someone who wants to take this on. As usual with
 performance problems, the devil is in the data collecting and pinpointing
 -- the fix (if there is one) is usually quite easy. But I'm sad to say
 that I'm formally giving up on this one. I have simply timed out if I am
 to graduate.

 I will say that I don't believe this ticket needs to be a release blocker.
  * T5631 still is worse by 30% in bytes allocated. This is a happy-
 generated file with lots of mutually-recursive functions with no type
 signatures, exactly the pathological case for representation polymorphism.
 I doubt we can bring this one back to 7.10 levels.
  * T5837 is off from before `TypeInType`. But it's still better than 7.10
 was!
  * T9675 has regressed in peak memory usage, but not allocations. This one
 doesn't seem to be representation polymorphism. But I couldn't nail it.
  * T9872 is an utter abuse of type families and looks nothing like a
 typical Haskell program.

 And those are the only cases that are worse than before `TypeInType`. Work
 between when this ticket was posted and now cleared up the others. I'll
 leave it to someone else to agree with me that this needn't be a release
 blocker before changing the priority.

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