我正在通过-prof编译来寻找Haskell程序中的优化机会,但是我不知道如何解释包含省略号的成本中心。什么是filter.(...)和jankRoulette.select.(...)?
COST CENTRE MODULE %time %alloc
filter.(...) Forest 46.5 22.3
set-union Forest 22.5 4.1
cache-lookup Forest 16.0 0.1
removeMany MultiMapSet 3.7 1.9
insertMany MultiMapSet 3.3 1.8
jankRoulette.select.(...) Forest 1.4 15.2我是用:$ ghc --make -rtsopts -prof -auto-all main.hs && ./main +RTS -p && cat main.prof生成的
函数filter在where子句中有几个定义,如下所示:
filter a b = blahblah where
foo = bar
bar = baz
baz = bing但这些都以filter.foo、filter.bar等的形式出现。
我认为它们可能是嵌套的let表达式,但是jankRoulette.select没有。我在他们的前面增加了SCC指令,没有任何成本中心上升到顶端。
由于大部分时间都是在filter.(...)上度过的,所以我想知道这是什么。:)
发布于 2015-05-13 17:55:25
TL;DR: GHC在let绑定中执行模式匹配时(如let (x,y) = c )生成这种情况。评估c的成本由...成本中心跟踪(因为它没有唯一的名称)。
那我是怎么发现的?在GHC源代码中,用于(...)的grep可以找到以下内容(来自编译器/deSugar/Coverage.hs):
-- TODO: Revisit this
addTickLHsBind (L pos (pat@(PatBind { pat_lhs = lhs, pat_rhs = rhs }))) = do
let name = "(...)"
(fvs, rhs') <- getFreeVars $ addPathEntry name $ addTickGRHSs False False rhs
{- ... more code following, but not relevant to this purpose
-}该代码告诉我们,它必须对模式绑定做一些事情。因此,我们可以制作一个小的测试程序来检查行为:
x :: Int
(x:_) = reverse [1..1000000000]
main :: IO ()
main = print x然后,我们可以在启用剖析的情况下运行这个程序。A确实,GHC生成以下输出:
COST CENTRE MODULE no. entries %time %alloc %time
%alloc
MAIN MAIN 42 0 0.0 0.0 100.0 100.0
CAF Main 83 0 0.0 0.0 100.0 100.0
(...) Main 86 1 100.0 100.0 100.0 100.0
x Main 85 1 0.0 0.0 0.0 0.0
main Main 84 1 0.0 0.0 0.0 0.0因此,从代码中得出的假设是正确的。程序的所有时间都用于评估reverse [1..1000000000]表达式,并将其分配给(...)成本中心。
https://stackoverflow.com/questions/30203566
复制相似问题