According to this article,
Enumerations don\'t count as single-constructor types as far as GHC is concerned, so they don\'t benefit from unpacking when us
It depends on the use case. For the functions you have, it's expected that the enumeration performs better. Basically, the three constructors of D
become Int
s resp. Int#
s when the strictness analysis allows that, and GHC knows it's statically checked that the argument can only have one of the three values 0#, 1#, 2#
, so it needs not insert error handling code for f
. For E
, the static guarantee of only one of three values being possible isn't given, so it needs to add error handling code for g
, that slows things down significantly. If you change the definition of g
so that the last case becomes
E _ -> 3535#
the difference vanishes completely or almost completely (I get a 1% - 2% better benchmark for f
still, but I haven't done enough testing to be sure whether that's a real difference or an artifact of benchmarking).
But this is not the use case the wiki page is talking about. What it's talking about is unpacking the constructors into other constructors when the type is a component of other data, e.g.
data FooD = FD !D !D !D
data FooE = FE !E !E !E
Then, if compiled with -funbox-strict-fields
, the three Int#
s can be unpacked into the constructor of FooE
, so you'd basically get the equivalent of
struct FooE {
long x, y, z;
};
while the fields of FooD
have the multi-constructor type D
and cannot be unpacked into the constructor FD
(1), so that would basically give you
struct FooD {
long *px, *py, *pz;
}
That can obviously have significant impact.
I'm not sure about the case of single-constructor function arguments. That has obvious advantages for types with contained data, like tuples, but I don't see how that would apply to plain enumerations, where you just have a case
and splitting off a worker and a wrapper makes no sense (to me).
Anyway, the worker/wrapper transformation isn't so much a single-constructor thing, constructor specialisation can give the same benefit to types with few constructors. (For how many constructors specialisations would be created depends on the value of -fspec-constr-count
.)
(1) That might have changed, but I doubt it. I haven't checked it though, so it's possible the page is out of date.