新类型比枚举更快吗？

根据本文 http://www.haskell.org/haskellwiki/Performance/Data_types,

就 GHC 而言，枚举不算作单构造函数类型，因此当用作严格构造函数字段或严格函数参数时，它们不会从解包中受益。这是 GHC 的缺陷，但可以解决。

相反，建议使用新类型。但是，我无法使用以下代码验证这一点：

{-# LANGUAGE MagicHash,BangPatterns #-}
{-# OPTIONS_GHC  -O2 -funbox-strict-fields -rtsopts -fllvm -optlc --x86-asm-syntax=intel #-}
module Main(main,f,g)
where       
import GHC.Base  
import Criterion.Main

data D = A | B | C
newtype E = E Int deriving(Eq)

f :: D -> Int#
f z | z `seq` False = 3422#
f z = case z of
  A -> 1234#
  B -> 5678#
  C -> 9012#

g :: E -> Int#
g z | z `seq` False = 7432#
g z = case z of
  (E 0) -> 2345#
  (E 1) -> 6789#
  (E 2) -> 3535#

f' x = I# (f x)
g' x = I# (g x)

main :: IO ()
main = defaultMain [ bench "f" (whnf f' A) 
                   , bench "g" (whnf g' (E 0)) 
                   ]

查看汇编代码，枚举 D 的每个构造函数的标记实际上已解包并直接硬编码在指令中。此外，函数f缺少错误处理代码，并且速度快 10% 以上g。在更现实的情况下，我在将枚举转换为新类型后也经历了速度减慢。谁能给我一些关于这个的见解？谢谢。

这取决于用例。对于您拥有的功能，预计枚举性能会更好。基本上，三个构造函数D become Ints resp. Int#当严格性分析允许时，并且 GHC 知道它已静态检查参数只能具有三个值之一0#, 1#, 2#，因此不需要插入错误处理代码f. For E，没有给出仅三个值之一可能的静态保证，因此需要添加错误处理代码g，这会显着减慢速度。如果你改变定义g这样最后一个案例就变成了

E _ -> 3535#

差异完全或几乎完全消失（我得到了 1% - 2% 更好的基准）f尽管如此，但我还没有进行足够的测试来确定这是否是真正的差异或基准测试的产物）。

但这不是 wiki 页面讨论的用例。它所说的是当类型是其他数据的组件时，例如，将构造函数解包到其他构造函数中。

data FooD = FD !D !D !D

data FooE = FE !E !E !E

然后，如果编译为-funbox-strict-fields， 他们三个Int#s 可以被解压到构造函数中FooE，所以你基本上会得到相当于

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⁽¹⁾, so that would basically give you

struct FooD {
    long *px, *py, *pz;
}

这显然会产生重大影响。

我不确定单构造函数参数的情况。对于包含数据的类型（例如元组）来说，这具有明显的优势，但我不知道这如何应用于普通枚举，在普通枚举中，您只有一个case将工人和包装机分开（对我来说）是没有意义的。

无论如何，工作者/包装器转换并不是单一构造函数的事情，构造函数专门化可以为具有很少构造函数的类型提供相同的好处。 （创建多少个构造函数专业化取决于-fspec-constr-count.)

⁽¹⁾ That might have changed, but I doubt it. I haven't checked it though, so it's possible the page is out of date.