Unknown - haskell-notes

строгой, но этого не достаточно, потому что в первом аргументе iter накапливаются вызовы tick. Сделаем

iter строгой по первому аргументу:

leak2 6 +RTS -K30m -hc

1,854,625 bytes x seconds

Fri Jun 1 21:38 2012

bytes

12M

10M

(102)main.xs/main/Main.CAF

8M

6M

(101)sum2.iter/sum2/main/M...

4M

2M

0M

0.0

0.0

0.0

0.1

0.1

0.1

0.1

0.1

0.2

0.2

0.2

seconds

Рис. 10.13: Опять двойка

sum2 ::[ Int] ->( Int, Int)

sum2 =iter (0, 0)

whereiter !c

[]

=c

iter !c

(x :xs) =iter (tick x c) xs

Теперь снова посмотрим на профиль:

$ ghc --make leak2.hs -rtsopts -prof -auto-all

$ ./leak2 6 +RTS -K30m -hc

(500000,500000)

$ hp2ps -e80mm -c leak2.hp

Мы видим (рис. 10.14), что память резко подскакивает и остаётся постоянной. Но теперь показатели

измеряются не в мегабайтах, а в килобайтах. Мы справились. Остальные флаги hX позволяют наблюдать за

разными специфическими объектами в куче. Мы можем узнать сколько памяти приходится на разные модули

(hm), сколько памяти приходится на разные конструкторы (hd), на разные типы замыканий (hy).

Поиск источников внезапной остановки

case-выражения и декомпозиция в аргументах функции могут стать источником очень неприятных оши-

бок. Программа прошла проверку типов, завелась и вот уже работает-работает как вдруг мы видим на экране:

*** Exception: Prelude.head :empty list

или

*** Exception: Maybe.fromJust : Nothing

И совсем не понятно откуда эта ошибка. В каком модуле сидит эта функция. Может мы её импортировали

из чужой библиотеки или написали сами. Как раз для таких случаев в GHC предусмотрен специальный флаг

xc.

Посмотрим на выполнение такой программы:

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

leak2 6 +RTS -hc

5,944 bytes x seconds

Fri Jun 1 21:51 2012

bytes

30k

(51)PINNED

25k

20k

(72)GHC.IO.Encoding.CAF

15k

(59)GHC.IO.Handle.FD.CAF

10k

(58)GHC.Conc.Signal.CAF

5k

0k

0.0

0.0

0.0

0.1

0.1

0.1

0.1

0.1

0.2

0.2

0.2

seconds

Рис. 10.14: Профиль кучи без утечки памяти

module Main where

addEvens :: Int -> Int -> Int

addEvens a b

|even a &&even b =a +b

q =zipWith addEvens [0, 2, 4, 6, 7, 8, 10] (repeat 0)

main =print q

Для того, чтобы воспользоваться флагом xc необходимо скомпилировать программу с возможностью про-

филирования:

$ ghc --make break.hs -rtsopts -prof

$ ./break +RTS -xc

*** Exception (reporting due to +RTS -xc): (THUNK_2_0), stack trace:

Main.CAF

break: break.hs:(4,1)-(5,30): Non-exhaustive patterns in function addEvens

Так мы узнали в каком месте кода проявился злосчастный вызов, это строки (4,1) -(5,30). Что соот-

ветствует определению функции addEvens. Не очень полезная информация. Мы и так бы это узнали. Нам

бы хотелось узнать тот путь, по которому шла программа к этому вызову. Проблема в том, что все вызовы

слились в один CAFдля модуля. Так разделим их:

$ ghc --make break.hs -rtsopts -prof -caf-all -auto-all

$ ./break +RTS -xc

*** Exception (reporting due to +RTS -xc): (THUNK_2_0), stack trace:

Main.addEvens,

called from Main.q,

called from Main.CAF:q

--> evaluated by: Main.main,

called from :Main.CAF:main

break: break.hs:(4,1)-(5,30): Non-exhaustive patterns in function addEvens

Теперь мы видим путь к этому вызову, мы пришли в него из знчения q, которое было вызвано из main.

10.7 Оптимизация программ

В этом разделе мы поговорим о том этапе компиляции, на котором происходят преобразования Core ->

Core. Мы называли этот этап упрощением программы.

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

Флаги оптимизации

Мы можем задавать степень оптимизации программы специальными флагами. Самые простые флаги на-

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

Поэтому не стоит увлекаться оптимизацией на начальном этапе проектирования. Посмотрим какие возмож-

ности у нас есть:

• без -O– минимум оптимизаций, код компилируется как можно быстрее.

• -O0– выключить оптимизацию полностью

• -O– умеренная оптимизация.

• O2– активная оптимизация, код компилируется дольше, но пока O2не сильно выигрывает у Oпо про-

дуктивности.

Для оптимизации мы компилируем программу с заданным флагом, например попробуйте скомпилиро-

вать самый первый пример с флагом O:

ghc --make sum.hs -O

и утечка памяти исчезнет.

Посмотреть описание конкретных шагов оптимизации можно в документации к GHC. Например при вклю-

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