Benchmarking GHC

Simon Marlow simonmarhaskell at
Mon Oct 23 08:06:48 EDT 2006

John Meacham wrote:
> On Fri, Oct 20, 2006 at 10:38:39AM +0100, Simon Marlow wrote:
>>I'm not sure that -funbox-strict-fields always improves performance, even 
>>if you only do it on Ints for example.  If you end up pulling out those 
>>fields and passing the Int to a lazy function, the Int will be re-boxed 
>>each time, leading to more allocation.  This is the reason that 
>>-funbox-strict-fields isn't on by defualt, and why I recommend using {-# 
>>UNPACK #-} pragmas.
> the happy medium I found in jhc was to always unbox any fields whose
> representation was smaller or equal to a pointer. It seems to work well.

Good idea.

> another worthwhile optimization that benefits from this is unboxing all
> enums.
> so 
> data Bool = False | True 
> desugars into
> data Bool = Bool# Int#
> False = Bool# 0#
> True = Bool# 1#

Right, this occurred to me too.  Alternatively we could have the strictness 
analyser represent a strict enumeration by Int# (I believe there's a ticket for 

I think when we discussed this for GHC the conclusion was that the latter was 
probably easier to implement, because we'd have to re-architect more of GHC to 
handle a data type with a representation that had a different number of 
constructors from the source data type (currently the difference between source 
and representation data types is only handled on a per-constructor basis).

Still, I prefer the Bool# solution because it seems to expose more to the 


More information about the Glasgow-haskell-users mailing list