PS: you may then be able to get rid of the call to `coreBindsSize` in `SimplCore`. If so, that would be good: faster compilation! Worth
#13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 -------------------------------------+------------------------------------- Reporter: hvr | Owner: rwbarton 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 -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:14 simonpj]: trying... it might I suppose show up another leak currently patched by `coreBindsSize`. The input core program size is used to bound the number of simplifier ticks so we can't remove the call to `coreBindsSize` entirely without affecting the behavior of the simplifier. I'm not sure whether we could make do with a more crude estimate of program size. However, `coreBindsSize` currently goes out of its way to force a lot of structure (like `seqBinds` does) that is not needed to compute the Core program size. So an easy intermediate option is to just remove all the extra `seq`s from `coreBindsSize`. This still leaves a lot less work than `coreBindsSize` does currently and forcing the main program body may be useful. I almost have this working but in order to fix another space leak I had to make another similar change of {{{#!hs simplExpr env expr = simplExprC env expr (mkBoringStop expr_out_ty) where expr_out_ty :: OutType expr_out_ty = substTy env (exprType expr) }}} to {{{#!hs simplExpr env expr = do { expr_out_ty <- simplType env (exprType expr) ; simplExprC env expr (mkBoringStop expr_out_ty) } }}} However, this also produces a lot of warnings like {{{ exprType TYPE: ModuleName }}} which seem to be from calling `simplExpr` on a `Type t`. Is it a bug that that happens in the first place? What is the best way to handle this? I get another smal improvement in space and time from this change so I'm hoping this is easy to finish off. Please advise! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13426#comment:18 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler