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

Question

I have a sieve of Eratosthenes program written in ST.Strict , and I was profiling it when I saw that it was taking a ridiculous amount of memory:

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)

(where 10^7) is the amount of primes I asked it to generate.

Weirdly, the profiling graph shows something completely different:

Am I misreading something in one of these graphs? Or is there something wrong with one of these tools?

For reference, my code is

{-# 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

This seems to confuse many people.

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

This is literally the total size of all the allocations ever performed by your program, including "temporary" objects that become dead almost immediately after being allocated. Allocation itself is nearly free, and generally Haskell programs allocate at a rate of around 1-2 GB/s.

Weirdly, the profiling graph shows something completely different:

Indeed, the profiling graph shows the total size of all the objects that are live on the heap at any particular time. This reflects the space usage of your program. If your program runs in constant space, then the number shown in this graph will stay constant.