#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