Adding a "release" setting in (and some other build system questions)

Nonce . voldermort at
Wed Feb 3 15:35:52 UTC 2016

> Date: Fri, 29 Jan 2016 17:44:56 +0100 
> Subject: Re: Adding a "release" setting in (and some  
> other build system questions) 
> From: thomasmiedema at 
> To: voldermort at 
> CC: ghc-devs at 
> The default (and thus release) `SRC_HC_OPTS` uses `-H32m` (see  
> mk/<>). 
> 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 <marlowsd at<mailto:marlowsd at>> 
> 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. 

For reference, there is some discussion in

Perhaps all of the -H options should be dropped from and the various build flavours, until it can be shown that some value is better than GHC's defaults for the overwhelming majority of builders? Even if I could show that some value works better for me, that doesn't mean it will work better for you or anyone else.

More information about the ghc-devs mailing list