Re: Increased memory usage with GHC 7.10.1

Actually, I meant only with -fno-specialise. On 13 April 2015 at 21:09, Michal Terepeta wrote:

On Mon, Apr 13, 2015 at 12:20 PM, Christiaan Baaij wrote:

...

Hi,

I wonder if this might be in any way related to the HUGE amount of new

...

https://ghc.haskell.org/trac/ghc/ticket/9630#comment:10

I don’t have a profiled version of GHC, so I was wondering if you could run your tests with a ‘-fno-specialise’, and see how everything performs

terms/types/coercions created by the specialiser as documented in: then?

...

Cheers,

Christiaan

Unfortunately trac is timing out for me, so I'll have a look at the issues later...

As for compiling haskell-src-exts with both -fno-specialise and -fno-call-arity, we're pretty much at the same level as GHC 7.8.4.

Mon Apr 13 20:25 2015 Time and Allocation Profiling Report (Final)

ghc +RTS -p -RTS [...] -fno-specialise -fno-call-arity

total time = 89.93 secs (89928 ticks @ 1000 us, 1 processor) total alloc = 93,495,685,792 bytes (excludes profiling overheads)

COST CENTRE MODULE %time %alloc

SimplTopBinds SimplCore 38.7 38.6 pprNativeCode AsmCodeGen 5.1 5.9 StgCmm HscMain 3.7 3.3 occAnalBind.assoc OccurAnal 3.2 3.6 OccAnal SimplCore 3.2 3.6 tc_rn_src_decls TcRnDriver 3.1 2.5 RegAlloc AsmCodeGen 3.1 4.2 regLiveness AsmCodeGen 3.0 3.5 FloatOutwards SimplCore 2.7 2.4 sink CmmPipeline 2.6 2.7 Simplify SimplCore 2.5 0.1 NewStranal SimplCore 1.9 2.3 genMachCode AsmCodeGen 1.8 1.7 layoutStack CmmPipeline 1.6 1.7 NativeCodeGen CodeOutput 1.4 1.5 FloatInwards SimplCore 1.2 1.6 CoreTidy HscMain 1.2 1.2 deSugar HscMain 1.2 1.2 do_block Hoopl.Dataflow 1.1 0.7 CorePrep HscMain 1.0 1.1 versioninfo MkIface 0.9 1.0 Parser HscMain 0.9 1.2 Digraph.scc Digraph 0.9 1.5 canEvVar TcCanonical 0.7 1.0