#13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3399, Wiki Page: | Phab:D3400, Phab:D3421 -------------------------------------+------------------------------------- Comment (by rwbarton): After writing comment:28 I got the validate results from Phab:D3421 which show a ~75% increase in allocations when compiling [https://raw.githubusercontent.com/ghc/ghc/master/testsuite/tests/perf/compil... T5631] which involves many very large types; the only change in that commit being to the `App fun arg` case of `simplExprF1`. I see that the `sc_arg_ty` is (almost) always used because it occurs as the type a function is applied to in the output program. But `sc_hole_ty` is only ever used via `contHoleType` and put in a `mkBoringStop`. There is even a Note `[The hole type in ApplyToTy]` which suggests that evaluating `sc_hole_ty` eagerly would be bad. I tried going back to using `substTy` for the `sc_hole_ty` field, while using `simplType` for the `sc_arg_ty` field. This still avoids the space leak when compiling `DynFlags` and also avoids the regression in T5631. So it seems to be the right thing to do. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13426#comment:30 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler