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 -------------------------------------+------------------------------------- Changes (by rwbarton): * differential: => Phab:D3399, Phab:D3400 Comment: Replying to [comment:14 simonpj]: trying... it might I suppose show up another leak currently patched by `coreBindsSize`. This line of investigation already paid some dividends. It turns out that that `coreBindsSize` is what takes care of forcing the demand and strictness info produced by the demand analysis pass. Otherwise, the demand analysis pass leaks basically a copy of the whole Core program. But ''late'' demand analysis runs after all simplifier passes, and there is no more `coreBindsSize` or `seqBinds` after that. Presumably code generation uses some of the information added by this pass, but it doesn't force all of it; and the result is that we hang on to two copies of the Core program during code generation. And code generation is the phase that uses the most memory anyways, so this makes a big difference in peak memory usage. As a crude measure I added a `seqBinds` to demand analysis (Phab:D3400) and it reduced peak memory usage on DynFlags by around 30% and even made the running time a few percent faster (I think because of reduced GC work). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13426#comment:17 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler