The default (and thus release) `SRC_HC_OPTS` uses `-H32m` (see mk/ config.mk.in).
Maybe you want to run some tests to see if it makes a difference on the total build time? I suggest also measuring without any `-H` flag, with just `-H` (see commit below), and with `-H1G` or some other large value. ``` commit 323950933d3260503186b93e7a5a7bdaa4822c1b Author: Simon Marlow <[email protected]> Date: Mon Nov 30 15:18:36 2009 +0000 Implement a new heap-tuning option: -H -H alone causes the RTS to use a larger nursery, but without exceeding the amount of memory that the application is already using. It trades off GC time against locality: the default setting is to use a fixed-size 512k nursery, but this is sometimes worse than using a very large nursery despite the worse locality. Not all programs get faster, but some programs that use large heaps do much better with -H. e.g. this helps a lot with #3061 (binary-trees), though not as much as specifying -H<large>. Typically using -H<large> is better than plain -H, because the runtime doesn't know ahead of time how much memory you want to use. Should -H be on by default? I'm not sure, it makes some programs go slower, but others go faster. ``` On Fri, Jan 29, 2016 at 2:47 PM, Harry . <[email protected]> wrote: > > > https://ghc.haskell.org/trac/ghc/wiki/MakingReleases#Makingthebinarybuilds > > https://ghc.haskell.org/trac/ghc/wiki/Building/Using#Buildconfiguration > > So the mysterious SRC_HC_OPTS = -O -H64m which appears in every build > flavour isn't used for the release build? > > _______________________________________________ > ghc-devs mailing list > [email protected] > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
