GHC分析文件和图表是矛盾的

Question

我在ST.Strict写了一个Eratosthenes程序的筛子，当我看到它带来了大量的记忆时，我正在剖析它：

Sun Jul 10 18:27 2016 Time and Allocation Profiling Report  (Final)

   Primes +RTS -hc -p -K1000M -RTS 10000000

total time  =        2.32 secs   (2317 ticks @ 1000 us, 1 processor)
total alloc = 5,128,702,952 bytes  (excludes profiling overheads)

（其中10 ^ 7）是我要求它生成的素数。

奇怪的是，分析图表显示了完全不同的东西：

我是否误读了其中一张图中的内容？或者其中一种工具有问题吗？

供参考，我的代码是

{-# LANGUAGE BangPatterns #-}

import Prelude hiding (replicate, read)
import qualified Text.Read as T
import Data.Vector.Unboxed.Mutable(replicate, write, read)
import Control.Monad.ST.Strict
import Data.STRef
import Control.Monad.Primitive

import Control.Monad

import System.Environment

main = print . length . primesUpTo . T.read . head =<< getArgs

primesUpTo :: Int -> [Int]
primesUpTo n = runST $ do
        primes <- replicate n True
        write primes 0 False
        write primes 1 False
        sieve 2 primes
        return []
        -- Removed to avoid the memory allocation of creating the list for profiling purposes
        -- filterM (read primes) [0..n-1]

    where
    sieve !i primes | i * i >= n    = return primes
    sieve !i primes = do
        v <- read primes i
        counter <- newSTRef $ i * i
        when v $ whileM_ ((< n) <$!> readSTRef counter) $ do
            curr_count <- readSTRef counter
            write primes curr_count False
            writeSTRef counter (curr_count + i)
        sieve (i + 1) primes

whileM_ :: (Monad m) => m Bool -> m a -> m ()
whileM_ condition body = do
    cond <- condition
    when cond $ do
        body
        whileM_ condition body

Answer 1

这似乎让很多人感到困惑。

total alloc = 5,128,702,952 bytes  (excludes profiling overheads)

这实际上是程序执行的所有分配的总大小，包括在分配后几乎立即死亡的“临时”对象。分配本身几乎是免费的，通常Haskell程序以大约1-2 GB / s的速率分配。

  

奇怪的是，分析图表显示了完全不同的东西：

实际上，分析图显示了在任何特定时间堆上的所有对象的总大小。这反映了程序的空间使用情况。如果您的程序在恒定的空间中运行，那么此图中显示的数字将保持不变。