下面的代码（在位置内联注释）给出了我所遇到的令人困惑的行为的最小示例。
从本质上讲，为什么（2）导致糟糕的时空性能而（1）却没有？
以下代码在ghc版本8.4.3上编译并运行如下：
ghc -prof -fprof-auto -rtsopts test.hs; ./test +RTS -p
{-# LANGUAGE Rank2Types #-}
import Debug.Trace
-- Not sure how to get rid of the record
data State = State {
-- (0) If vstate :: Float, the extra "hello"s go away
vstate :: forall a . (Fractional a) => a
}
step :: State -> State
step s =
-- (1) one "hello" per step
-- let vs = trace "hello" (vstate s) in
-- s { vstate = vs `seq` vstate s }
-- (2) increasing "hello"s per step
s { vstate = (trace "hello" (vstate s)) `seq` vstate s }
main :: IO ()
main = do
let initState = State { vstate = 0 }
-- (3) step 3 times
-- let res = step $ step $ step initState
-- print $ vstate res
-- (4) step 20 times to profile time/space performance
let res = iterate step initState
print $ vstate $ last $ take 20 res
print "done"
a。加上（1）和（3）的注释，而没有-O2进行编译，该代码仅输出“ hello” 3次，正如我期望的那样。
b。注释掉（2）和（3），并在没有-O2的情况下进行编译，该代码将输出“ hello”八次。似乎每步输出一个额外的“ hello”。 我不明白为什么会这样。
c。注释掉（1）和（4），并在没有-O2的情况下进行编译，代码运行非常快。
-O2的情况下进行编译，代码运行非常缓慢，性能报告（如下所示）显示，对vstate的调用更多，并且使用了更多的内存。而不是变体c。 我也不明白为什么会这样。
e。注释（2）和（4），并用 -O2编译后，代码的行为与变量c相同。因此，显然ghc能够优化变体d中发生的任何病理行为。
以下是变体c的性能分析报告（快速）：
Mon Aug 13 15:48 2018 Time and Allocation Profiling Report (Final)
partial +RTS -p -RTS
total time = 0.00 secs (0 ticks @ 1000 us, 1 processor)
total alloc = 107,560 bytes (excludes profiling overheads)
COST CENTRE MODULE SRC %time %alloc
CAF GHC.IO.Handle.FD <entire-module> 0.0 32.3
CAF GHC.IO.Encoding <entire-module> 0.0 3.1
main Main partial.hs:(24,1)-(35,16) 0.0 13.4
main.res Main partial.hs:32:9-36 0.0 1.6
step Main partial.hs:(15,1)-(18,36) 0.0 1.1
step.vs Main partial.hs:17:9-37 0.0 46.1
individual inherited
COST CENTRE MODULE SRC no. entries %time %alloc %time %alloc
MAIN MAIN <built-in> 114 0 0.0 0.6 0.0 100.0
CAF Main <entire-module> 227 0 0.0 0.1 0.0 52.2
main Main partial.hs:(24,1)-(35,16) 228 1 0.0 2.7 0.0 52.1
vstate Main partial.hs:11:5-10 230 20 0.0 0.0 0.0 0.0
main.initState Main partial.hs:25:9-40 239 0 0.0 0.0 0.0 0.0
main.res Main partial.hs:32:9-36 234 0 0.0 0.0 0.0 0.0
step Main partial.hs:(15,1)-(18,36) 235 0 0.0 0.0 0.0 0.0
main.initState Main partial.hs:25:9-40 233 1 0.0 0.0 0.0 0.0
main.res Main partial.hs:32:9-36 231 1 0.0 1.6 0.0 49.4
step Main partial.hs:(15,1)-(18,36) 232 19 0.0 1.1 0.0 47.8
step.vs Main partial.hs:17:9-37 236 19 0.0 46.1 0.0 46.7
vstate Main partial.hs:11:5-10 237 190 0.0 0.0 0.0 0.6
main.initState Main partial.hs:25:9-40 238 0 0.0 0.6 0.0 0.6
CAF Debug.Trace <entire-module> 217 0 0.0 0.2 0.0 0.2
CAF GHC.Conc.Signal <entire-module> 206 0 0.0 0.6 0.0 0.6
CAF GHC.IO.Encoding <entire-module> 189 0 0.0 3.1 0.0 3.1
CAF GHC.IO.Encoding.Iconv <entire-module> 187 0 0.0 0.2 0.0 0.2
CAF GHC.IO.Handle.FD <entire-module> 178 0 0.0 32.3 0.0 32.3
CAF GHC.IO.Handle.Text <entire-module> 176 0 0.0 0.1 0.0 0.1
main Main partial.hs:(24,1)-(35,16) 229 0 0.0 10.7 0.0 10.7
以下是变体d的性能分析报告（慢；没有-O2）：
Mon Aug 13 15:25 2018 Time and Allocation Profiling Report (Final)
partial +RTS -p -RTS
total time = 1.48 secs (1480 ticks @ 1000 us, 1 processor)
total alloc = 1,384,174,472 bytes (excludes profiling overheads)
COST CENTRE MODULE SRC %time %alloc
step Main partial.hs:(15,1)-(21,60) 95.7 98.8
main.initState Main partial.hs:25:9-40 3.0 1.2
vstate Main partial.hs:11:5-10 1.4 0.0
individual inherited
COST CENTRE MODULE SRC no. entries %time %alloc %time %alloc
MAIN MAIN <built-in> 114 0 0.0 0.0 100.0 100.0
CAF Main <entire-module> 227 0 0.0 0.0 100.0 100.0
main Main partial.hs:(24,1)-(35,16) 228 1 0.0 0.0 100.0 100.0
vstate Main partial.hs:11:5-10 230 1048575 1.4 0.0 100.0 100.0
main.initState Main partial.hs:25:9-40 236 0 3.0 1.2 3.0 1.2
main.res Main partial.hs:32:9-36 234 0 0.0 0.0 95.7 98.8
step Main partial.hs:(15,1)-(21,60) 235 0 95.7 98.8 95.7 98.8
main.initState Main partial.hs:25:9-40 233 1 0.0 0.0 0.0 0.0
main.res Main partial.hs:32:9-36 231 1 0.0 0.0 0.0 0.0
step Main partial.hs:(15,1)-(21,60) 232 19 0.0 0.0 0.0 0.0
CAF Debug.Trace <entire-module> 217 0 0.0 0.0 0.0 0.0
CAF GHC.Conc.Signal <entire-module> 206 0 0.0 0.0 0.0 0.0
CAF GHC.IO.Encoding <entire-module> 189 0 0.0 0.0 0.0 0.0
CAF GHC.IO.Encoding.Iconv <entire-module> 187 0 0.0 0.0 0.0 0.0
CAF GHC.IO.Handle.FD <entire-module> 178 0 0.0 0.0 0.0 0.0
CAF GHC.IO.Handle.Text <entire-module> 176 0 0.0 0.0 0.0 0.0
main Main partial.hs:(24,1)-(35,16) 229 0 0.0 0.0 0.0 0.0
以下是有关发生这种情况的一些注释/猜测/问题：
vstate单一化为vstate :: Float时，病理行为消失了。但是我不明白为什么在位置（2）中缺少let绑定会导致如此差的时间/空间性能。realToFrac对浮点型数字进行“单态化”来解决（如果有人好奇，则提交为here）。我知道用-O2进行编译可以在最小的示例中解决此问题，但是我在较大的代码库中尝试了此操作，但不能解决性能问题。 （我们在较大的代码库中需要等级2多态性的原因是使用ad库进行autodiff。）是否有比使用realToFrac更有原则的修复，例如可以应用的内联专门化？答案 0 :(得分：4)
forall a . (Fractional a) => a是一种函数类型。
它有两个参数，类型为(a :: *)和实例类型为Fractional a。每当您看到=>时，它在操作上就是一个函数，并且会以GHC的核心表示形式编译为一个函数，有时还会在机器代码中保留为一个函数。 ->和=>之间的主要区别在于，程序员无法明确给出后者的参数，并且它们始终由实例解析隐式地填充。
让我们首先看看快速的step：
step :: State -> State
step (State f) =
let vs = trace "hello" f
in State (vs `seq` f)
在这里，vs的类型Fractional不确定，默认为Double。如果您打开-Wtype-defaults警告，GHC会向您指出。从vs :: Double开始，它只是一个数值，由返回的 closure 捕获。是的，vs `seq` f是一个函数，因为它具有函数类型forall a . (Fractional a) => a，并且已由GHC替换为实际的lambda表达式。此lambda抽象化两个参数，将vs捕获为自由变量，然后将两个参数传递给f。
因此，每个step都会创建一个新的函数闭包，该闭包捕获vs :: Double。如果我们调用step三次，我们将获得三个闭包，其中包含三个Double，每个闭包均引用前一个闭包。然后，当我们编写vstate (step $ step $ step initState)时，我们再次默认为Double，GHC用Fractional Double实例调用此闭包。所有vs-es都使用Fractional Double调用先前的闭包，但是每个vs仅被评估一次，因为它们是常规的惰性Double值，不会重新计算。
但是，如果启用NoMonomorphismRestriction，则vs会被通用化为forall a. Fractional a => a，因此它也成为一个函数，并且其调用也不再被记忆。因此，在这种情况下，快速版本的行为与慢速版本相同。
现在，缓慢的step：
step :: State -> State
step (State f) = State ((trace "hello" f) `seq` f)
此步骤的调用次数为指数个，因为step f调用了f两次，并且没有优化就没有共享计算，因为这两个调用都是在lambda。在(trace "hello" f) `seq` f中，对f的第一次调用默认为Fractional Double，而第二次调用只是像以前一样传递隐式Fractional a实例。
如果我们打开优化功能，GHC会发现第一个f调用不依赖于函数参数，并且将trace "hello" f浮动到一个let绑定中，导致代码与在快速版本中。