在调查一些图书馆中一些奇怪的基准测试结果，我偶然发现了一些我不明白的行为，虽然这可能是很明显的。看来，许多操作(创建新的MutableArray，读取或修改IORef)所需的时间与内存中的数组数成比例增加。
这里是第一个例子：
module Main
where
import Control.Monad
import qualified Data.Primitive as P
import Control.Concurrent
import Data.IORef
import Criterion.Main
import Control.Monad.Primitive(PrimState)
main = do
let n = 100000
allTheArrays <- newIORef []
defaultMain $
[ bench "array creation" $ do
newArr <- P.newArray 64 () :: IO (P.MutableArray (PrimState IO) ())
atomicModifyIORef' allTheArrays (\l-> (newArr:l,()))
]
我们正在创建一个新的数组并将其添加到堆栈。作为标准，更多的样本和堆栈增长，数组创建需要更多的时间，这似乎是线性和规律地增长：
更奇怪的是，IORef的读写操作受到影响，我们可以看到atomicModifyIORef’更快的估计是更多的数组是GC’d。
main = do
let n = 1000000
arrs <- replicateM (n) $ (P.newArray 64 () :: IO (P.MutableArray (PrimState IO) ()))
-- print $ length arrs -- THIS WORKS TO MAKE THINGS FASTER
arrsRef <- newIORef arrs
defaultMain $
[ bench "atomic-mods of IORef" $
-- nfIO $ -- OR THIS ALSO WORKS
replicateM 1000 $
atomicModifyIORef' arrsRef (\(a:as)-> (as,()))
]
评论的两行之一摆脱了这种行为，但我不知道为什么(也许在我们强制的列表的脊柱之后，元素实际上可以通过收集)。
问题
>这里发生了什么？
>它是预期的行为吗？
>有没有办法，我可以避免这种放缓？
编辑：我认为这与GC有关，需要更长的时间，但我想更准确地了解发生了什么，特别是在第一个基准。
奖金示例
最后，这里有一个简单的测试程序，可以用来预分配一些数组和时间一堆atomicModifyIORefs。这似乎表现出慢IORef行为。
import Control.Monad import System.Environment import qualified Data.Primitive as P import Control.Concurrent import Control.Concurrent.Chan import Control.Concurrent.MVar import Data.IORef import Criterion.Main import Control.Exception(evaluate) import Control.Monad.Primitive(PrimState) import qualified Data.Array.IO as IO import qualified Data.Vector.Mutable as V import System.cpuTime import System.Mem(performGC) import System.Environment main :: IO () main = do [n] <- fmap (map read) getArgs arrs <- replicateM (n) $ (P.newArray 64 () :: IO (P.MutableArray (PrimState IO) ())) arrsRef <- newIORef arrs t0 <- getcpuTimeDouble cnt <- newIORef (0::Int) replicateM_ 1000000 $ (atomicModifyIORef' cnt (\n-> (n+1,())) >>= evaluate) t1 <- getcpuTimeDouble -- make sure these stick around readioRef cnt >>= print readioRef arrsRef >>= (flip P.readArray 0 . head) >>= print putStrLn "The time:" print (t1 - t0)
带有-hy的堆配置文件主要显示为MUT_ARR_PTRS_CLEAN，我不完全理解。
如果你想重现，这里是我一直在使用的cabal文件
name: small-concurrency-benchmarks version: 0.1.0.0 build-type: Simple cabal-version: >=1.10 executable small-concurrency-benchmarks main-is: Main.hs build-depends: base >=4.6,criterion,primitive default-language: Haskell2010 ghc-options: -O2 -rtsopts
编辑：这里是另一个测试程序，可以用于比较减缓与相同大小的阵列vs [整数]的堆。它需要一些试验和错误调整n和观察分析，以获得类似的运行。
main4 :: IO () main4= do [n] <- fmap (map read) getArgs let ns = [(1::Integer).. n] arrsRef <- newIORef ns print $ length ns t0 <- getcpuTimeDouble mapM (evaluate . sum) (tails [1.. 10000]) t1 <- getcpuTimeDouble readioRef arrsRef >>= (print . sum) print (t1 - t0)
有趣的是，当我测试这个，我发现相同的堆大小的数组的数组影响性能的程度大于[Integer]。例如。
Baseline 20M 200M Lists: 0.7 1.0 4.4 Arrays: 0.7 2.6 20.4
结论(WIP)
>这很可能是由于GC行为
>但是可变的unBoxed数组似乎导致更多的服务器减速(见上文)。设置RTS -A200M使数组垃圾版本的性能符合列表版本，支持这与GC有关。
>减速与分配的阵列数量成比例，而不是阵列中总单元数。这里是一组运行，显示，对于类似的测试，main4，分配的数量分配的时间分配的时间和一个完全不相关的“有效载荷”的影响。这是为16777216总细胞(分为许多阵列)：
Array size Array create time Time for "payload": 8 3.164 14.264 16 1.532 9.008 32 1.208 6.668 64 0.644 3.78 128 0.528 2.052 256 0.444 3.08 512 0.336 4.648 1024 0.356 0.652
并且在16777216 * 4单元上运行相同的测试，显示与上面基本相同的有效负载时间，仅向下移动两个位置。
>从我理解GHC的工作原理，看看(3)，我认为这种开销可能只是指向所有这些数组贴在周围的remembered set(参见：here)，以及任何开销导致GC。
