Что заставляет мой анализатор Wavefront Obj потреблять в 10 раз больше памяти, чем вход?

Я пытаюсь написать синтаксический анализатор для формата Wavefront .obj, который является действительно тупым линейным форматом. Надеемся, что статья wikipedia должна обобщать, как она работает, но по существу у вас есть строки, которые записывают записи в вершинные, нормальные и другие массивы. Наконец, определение лица является тройным (или более) индексом в эти отдельные массивы.

Мой парсер

{-# LANGUAGE BangPatterns #-}
{-# LANGUAGE OverloadedStrings #-}
module WavefrontObj where

import Control.Applicative
import Data.Attoparsec.Text
import Data.Foldable (toList)
import Data.List (foldl')
import Data.List.Split
import Data.Monoid
import Data.NonEmpty ((!:))
import Data.Sequence (Seq)
import Geometry
import Graphics.GL
import Linear
import Linear.Affine
import qualified Data.Sequence as Seq

data Obj =
  Obj {objVertices :: !(Seq (V3 Double))
      ,objNormals :: !(Seq (V3 Double))
      ,objFaces :: !(Seq (V2 (V3 Int)))}
  deriving (Show)

instance Monoid Obj where
  mempty = Obj mempty mempty mempty
  Obj a b c `mappend` Obj x y z =
    Obj (a <> x)
        (b <> y)
        (c <> z)

parseLine :: Parser Obj
parseLine =
  vertex <|> normal <|> face <|>
  (mempty <$ skipWhile (not . isEndOfLine))
  where vertex =
          do string "v"
             skipSpace
             v <- v3
             return $!
               Obj (Seq.singleton v) mempty mempty
        normal =
          do string "vn"
             skipSpace
             v <- v3
             return $!
               Obj mempty (Seq.singleton v) mempty
        face =
          do string "f"
             skipSpace
             let v =
                   (,) <$> decimal <* char '/' <* decimal <* char '/' <*> decimal
             (v1,n1) <- v
             skipSpace
             (v2,n2) <- v
             skipSpace
             (v3,n3) <- v
             mv4 <-
               optional (do skipSpace
                            v)
             return $!
               Obj mempty
                   mempty
                   (Seq.singleton
                      (V2 (V3 v1 v2 v3)
                          (V3 n1 n2 n3)) <>
                    case mv4 of
                      Just (v4,n4) ->
                        Seq.singleton
                          (V2 (V3 v1 v3 v4)
                              (V3 n1 n3 n4))
                      Nothing -> mempty)
        v3 =
          do x <- double
             skipSpace
             y <- double
             skipSpace
             z <- double
             return $! V3 x y z

parseObj :: Parser Obj
parseObj = go mempty
  where go !acc =
          do !l <- parseLine
             acc' <- return $! acc <> l
             endOfLine *> go acc' <|> acc' <$ endOfInput

Запуск этого процесса с помощью файла obj файла 36 Мб выполняется успешно, но

  21,342,866,200 bytes allocated in the heap
   1,263,590,520 bytes copied during GC
     290,617,624 bytes maximum residency (10 sample(s))
      56,958,112 bytes maximum slop
             547 MB total memory in use (0 MB lost due to fragmentation)

                                     Tot time (elapsed)  Avg pause  Max pause
  Gen  0     41177 colls,     0 par    0.711s   0.708s     0.0000s    0.0008s
  Gen  1        10 colls,     0 par    0.241s   0.241s     0.0241s    0.1669s

  INIT    time    0.000s  (  0.000s elapsed)
  MUT     time    5.071s  (  5.077s elapsed)
  GC      time    0.952s  (  0.949s elapsed)
  RP      time    0.000s  (  0.000s elapsed)
  PROF    time    0.000s  (  0.000s elapsed)
  EXIT    time    0.020s  (  0.020s elapsed)
  Total   time    6.055s  (  6.046s elapsed)

  %GC     time      15.7%  (15.7% elapsed)

  Alloc rate    4,208,709,362 bytes per MUT second

  Productivity  84.3% of total user, 84.4% of total elapsed

В то время как производительность хорошая, 6 секунд, чтобы открыть файл .obj с общим объемом памяти 547 Мбайт, кажется чрезмерным. Я загрузил профиль кучи здесь. Файл .prof

    Fri Jun  5 22:36 2015 Time and Allocation Profiling Report  (Final)

       Deferred +RTS -p -RTS

    total time  =        5.17 secs   (5173 ticks @ 1000 us, 1 processor)
    total alloc = 13,142,553,520 bytes  (excludes profiling overheads)

COST CENTRE      MODULE                %time %alloc

parseLine.v3     WavefrontObj           69.8   69.5
parseLine.face.v WavefrontObj            8.4   13.7
parseLine.face   WavefrontObj            7.0    6.1
timeLog          Deferred                3.3    1.2
parseLine        WavefrontObj            2.8    1.7
parseLine.normal WavefrontObj            2.5    3.6
readTextDevice   Data.Text.Internal.IO   2.2    0.1
parseLine.vertex WavefrontObj            1.7    2.6
mappend          WavefrontObj            1.4    1.1


                                                                           individual     inherited
COST CENTRE              MODULE                          no.     entries  %time %alloc   %time %alloc

MAIN                     MAIN                             85           0    0.0    0.0   100.0  100.0
 main                    Deferred                        171           0    0.0    0.0   100.0  100.0
  timeLog                Deferred                        173           0    3.3    1.2   100.0  100.0
   parseObj              WavefrontObj                    178           0    0.0    0.0    94.4   98.7
    parseObj.go          WavefrontObj                    179     1080806    0.6    0.5    94.4   98.7
     parseLine           WavefrontObj                    181           0    2.8    1.7    93.8   98.2
      parseLine.v3       WavefrontObj                    190           0   69.7   69.5    70.8   70.3
       mappend           WavefrontObj                    191      667027    1.0    0.8     1.0    0.8
      parseLine.face     WavefrontObj                    187           0    7.0    6.1    16.9   21.3
       parseLine.face.v  WavefrontObj                    195           0    8.4   13.7     9.7   15.2
        parseLine.normal WavefrontObj                    196           0    0.9    1.3     1.2    1.5
         mappend         WavefrontObj                    197      127769    0.3    0.3     0.3    0.3
       parseLine.normal  WavefrontObj                    193           0    0.0    0.0     0.0    0.0
       mappend           WavefrontObj                    188      286011    0.1    0.0     0.1    0.0
      parseLine.normal   WavefrontObj                    185           0    1.5    2.3     1.6    2.3
       parseLine.v3      WavefrontObj                    192           0    0.1    0.0     0.1    0.0
      parseLine.vertex   WavefrontObj                    183           0    1.7    2.6     1.7    2.6
   readTextDevice        Data.Text.Internal.IO           174       18260    2.2    0.1     2.2    0.1
 CAF                     Deferred                        169           0    0.0    0.0     0.0    0.0
  main                   Deferred                        170           1    0.0    0.0     0.0    0.0
   timeLog               Deferred                        172           1    0.0    0.0     0.0    0.0
 CAF                     WavefrontObj                    166           0    0.0    0.0     0.0    0.0
  parseLine              WavefrontObj                    180           1    0.0    0.0     0.0    0.0
   parseLine.v3          WavefrontObj                    189           1    0.0    0.0     0.0    0.0
   parseLine.face        WavefrontObj                    186           1    0.0    0.0     0.0    0.0
    parseLine.face.v     WavefrontObj                    194           1    0.0    0.0     0.0    0.0
   parseLine.normal      WavefrontObj                    184           1    0.0    0.0     0.0    0.0
   parseLine.vertex      WavefrontObj                    182           1    0.0    0.0     0.0    0.0
  mempty                 WavefrontObj                    176           1    0.0    0.0     0.0    0.0
  parseObj               WavefrontObj                    175           1    0.0    0.0     0.0    0.0
   parseObj.go           WavefrontObj                    177           1    0.0    0.0     0.0    0.0
 CAF                     Data.Attoparsec.Text.Internal   153           0    0.0    0.0     0.0    0.0
 CAF                     Data.Scientific                 152           0    0.0    0.0     0.0    0.0
 CAF                     Data.Text.Array                 150           0    0.0    0.0     0.0    0.0
 CAF                     Data.Text.Internal              148           0    0.0    0.0     0.0    0.0
 CAF                     GHC.Err                         135           0    0.0    0.0     0.0    0.0
 CAF                     GHC.IO.Handle.FD                132           0    0.0    0.0     0.0    0.0
 CAF                     GHC.IO.Handle.Internals         131           0    0.0    0.0     0.0    0.0
 CAF                     GHC.Conc.Signal                 125           0    0.0    0.0     0.0    0.0
 CAF                     GHC.IO.Encoding                 121           0    0.0    0.0     0.0    0.0
 CAF                     GHC.IO.FD                       120           0    0.0    0.0     0.0    0.0
 CAF                     GHC.Conc.Sync                   108           0    0.0    0.0     0.0    0.0
 CAF                     GHC.IO.Encoding.Iconv           106           0    0.0    0.0     0.0    0.0
 CAF                     GHC.Integer.Type                 92           0    0.0    0.0     0.0    0.0

У меня есть предположение, что, поскольку моя точка доступа является парсером v3, это может быть просто связано с использованием парсера double.

ОТВЕТЫ

Ответ 1

Я считаю, что ваша проблема заключается в определении Obj:

data Obj =
  Obj {objVertices :: !(Seq (V3 Double))
      ,objNormals :: !(Seq (V3 Double))
      ,objFaces :: !(Seq (V2 (V3 Int)))}
  deriving (Show)

В вашем парсере вы используете только одно из трех полей, но вы оцениваете значение WHNF и выделяете пространство для пустой последовательности для каждого Obj. Это почти утроит пространство Obj в памяти по сравнению с его размером в текстовом файле. У вас также всегда есть экземпляр Seq.singleton (также оцениваемый для WHNF) для каждого элемента. Вы платите за это время и память.

Вы можете сказать: "Но все мое время тратится на v3", и вы будете правы. Однако все это время тратится на выделение памяти, которая (я думаю?) Включает в себя стоимость запуска сборщика мусора. Статистически вы, скорее всего, поймаете GC-циклы, в которых вы будете выполнять наибольшее распределение.

Мои предложения:

  • Посмотрите, что произойдет, если вы берете строгость из Obj, возможно, это не работает как полное решение, но оно покажет вам, если это проблема для стоимости удаления трех !. Если я ошибаюсь, вы потеряли очень мало.
  • Преобразовать Obj в тип суммы вместо типа продукта.
  • Использовать более обычный парсер. Parsec является удивительным, когда дело доходит до чистой экспресс-способности и сложности грамматик, с которыми он может справиться, но просто не в том же классе, что и другие более ограниченные методы анализа.

Возможный тип суммы для Obj:

data Obj =
    Empty 
  | Vertex (V3 Double)
  | Normal (V3 Double)
  | Face   (V2 (V3 Int))
  | Obj {objVertices :: !(Seq (V3 Double))
        ,objNormals  :: !(Seq (V3 Double))
        ,objFaces    :: !(Seq (V2 (V3 Int)))}

Instance Monoid Obj where
  mempty = Empty
  mappend Empty x = x
  mappend x Empty = x
  mappend (Face v) ([email protected]{objFaces = vs}) = obj{objFaces = v<|vs}
  mappend ([email protected]{objFaces = vs}) (Face v) = obj{objFaces = vs |> v}
  ...

Ответ 2

По моему опыту, ответ на синтаксический анализ на основе строк - это использование BS.lines и BS.words из Data.ByteString.Char8. Это не очень красиво, но подход парсер-комбайнера не слишком эффективен или эффективен. Что-то вроде:

parseLine :: BS.ByteString -> [Either Xxx Obj]
parseLine = map prs . BS.lines

prs :: BS.ByteString -> Either Xxx Obj
prs l = case BS.words l of
         ["v", x, y, z] -> do
             v <- V3 <$> parseDouble x <*> parseDouble y <*> parseDouble z
             return $ Obj (Seq.singleton v) mempty mempty
         ...
         _ -> Left "blah"

Это для производительности. Для использования памяти вы, вероятно, захотите использовать примитивные векторы и распакованные типы данных. В вашем примере это не похоже, но вам также нужно проверить, как библиотеки, которые вы используете, реализуете свои типы данных. Например, UTCTime из пакета time использует много памяти.

Окончательный совет: я обычно параметризую свои типы данных с типом "строки", который они используют. Мои функции парсера возвращают Foo ByteString, и я конвертирую в Foo Text подмножество, которое я буду хранить в памяти и манипулировать.