Unknown - haskell-notes

1 colls,

0 par

0.00s

0.00s

0.0001s

0.0001s

...

MUT

time

0.01s

(

0.01s elapsed)

GC

time

0.00s

(

0.00s elapsed)

...

%GC

time

0.0%

(11.8% elapsed)

Статистика выполнения программы | 165

Мы видим, что за счёт уменьшения памяти очистки существенно участились, но это не сказалось на об-

щем результате. С помощью флага H[size] мы можем устанавливать рекомендуемое минимальное значение

для размера кучи. Оно точно не будет меньше. Вернёмся к первому варианту и выделим алгоритму побольше

памяти, например 20 Мб:

./sum +RTS -A1m -H20m -sstderr

5.00005e9

14,145,284 bytes allocated inthe heap

319,716 bytes copied during GC

324,136 bytes maximum residency (1 sample(s))

60,888 bytes maximum slop

22 MBtotal memory inuse (1 MBlost due to fragmentation)

Tottime (elapsed)

Avgpause

Maxpause

Gen

0

2 colls,

0 par

0.00s

0.00s

0.0001s

0.0001s

Gen

1

1 colls,

0 par

0.00s

0.00s

0.0007s

0.0007s

INIT

time

0.00s

(

0.00s elapsed)

MUT

time

0.02s

(

0.02s elapsed)

GC

time

0.00s

(

0.00s elapsed)

EXIT

time

0.00s

(

0.00s elapsed)

Total

time

0.02s

(

0.02s elapsed)

%GC

time

0.0 %

(4.4 %elapsed)

Allocrate

884,024,998 bytes per MUTsecond

Productivity100.0 % oftotal user, 78.6 % oftotal elapsed

Произошла лишь одна глубокая очистка (похоже, что эта очистка соответствует начальному выделению

памяти) и продуктивность программы стала стопроцентной. С помощью флага Sвместо s мы можем по-

смотреть более детальную картину управления памяти. Будут распечатаны показатели памяти для каждой

очистки.

./sum +RTS -Sfile

В файле file мы найдём такую таблицу:

память

время

выделено скопировано в живых

GC

Total

Тип очистки

Alloc

Copied

Live

GC

GC

TOT

TOT

Page Flts

bytes

bytes

bytes

user

elap

user

elap

545028

150088

174632

0.00

0.00

0.00

0.00

0

0

( Gen:

1)

523264

298956

324136

0.00

0.00

0.00

0.00

0

0

( Gen:

0)

...

Итак у нас появился один существенный показатель качества программ. Это количество глубоких очи-

сток. Во время глубокой очистки вычислитель производит две затратные операции: сканирование всей кучи

и запрос у системы возможно большого блока памяти. Чем меньше таких очисток, тем лучше. Сократить их

число можно удачной комбинацией показателей Aи H. Но не стоит сразу начинать обновлять параметры по

умолчанию, если ваша программа работает слишком медленно. Лучше сначала попробовать изменить ал-

горитм. Найти функцию, которая слишком много ленится и ограничить её с помощью seq или энергичных

образцов. В этом примере у нас была всего одна функция, поэтому поиск не составил труда. Но что если их

уже очень много? Скорее всего так и будет. Не стоит оптимизировать не рабочую программу. А в рабочей

программе обычно много функций. Но это не так страшно, помимо суммарных показателей GHC позволяет

собирать более конкретную статистику.

Стоит отметить функцию performGC из модуля System.Mem, она форсирует поверхностную сборку мусора.

Допустим вы чистаете какие-то данные из файла и тут же преобразуете их в структуру данных. После того

как чтение данных закончится, вы знаете, что промежуточные данные связаные с чтением вам уже не нужны.

Выполнив performGC вы можете подсказать об этом вычислителю.

Профилирование функций

Время и общий объём памяти

Процесс отслеживания показателей память/скорость называется профилированием программы. Всё вро-

де бы работает, но работает слишком медленно, необходимо установить причину. Рассмотрим такую про-

грамму:

166 | Глава 10: Реализация Haskell в GHC

module Main where

concatR =foldr ( ++) []

concatL =foldl ( ++) []

fun :: Double

fun =test concatL -test concatR

wheretest f =last $f $map return [1 ..1e6]

main =print fun

У нас есть подозрение, что какая-то из двух функций concatX работает слишком медленно. Мы можем

посмотреть какая, если добавим к ним специальную прагму SCC:

concatR ={-# SCC ”right” #-} foldr ( ++) []

concatL ={-# SCC ”left”