Кратко: типичные причины space‑leak в ленивом Haskell — накопление неизвычисленных thunk'ов или удержание ссылок на начало данных; обнаружение — GHC‑профайлинг и RTS‑статистика; исправление — ввести строгость (strict folds / seq / BangPatterns / строгие поля), или сменить модель на потоки/стриминг. Ниже — детали и конкретные приёмы.
Типичные причины
- Ленивое аккумулятивное свёртывание: например
sumBad xs = foldl (+) 0 xs
приводит к накоплению thunk'ов вида $(...((0+x_1)+x_2)+\cdots +x_n)$ вместо немедленного суммирования.
- Использование scanl/iterate или других функций, которые возвращают список промежуточных результатов, а затем выбор только конечного значения — вся последовательность остаётся в памяти.
- Удержание головы списка в закрытии (closure) — замыкание содержит ссылку на начало списка, поэтому GC не может освободить уже пройденные элементы.
- Ленивые поля в структурах данных: если поле типа содержит ленивое значение, то в структуре могут накапливаться thunk'ы.
- Lazy I/O / ленивые ByteString/Text: неправильное потребление ленивого ввода может удерживать большие буферы.
- Накопление арифметических thunk'ов при больших числовых вычислениях (неприменённый seq/strictness).
- Использование (++) для конкатенации в цикле (амортизированно дорого по памяти, может держать промежуточные списки).
Обнаружение утечек
- Добавить RTS‑статистику: запустить с опциями RTS, например: ./prog +RTS -s -RTS — посмотреть резюме GC/памяти.
- Включить профилирование кучи: скомпилировать с GHC флагами `-prof -fprof-auto -rtsopts`, запустить с RTS опциями для heap profiling (например `+RTS -hc -RTS`), получить .hp файл и визуализировать (hp2ps / инструменты профайлинга).
- Использовать профайлер по затратам (cost‑centre) и по удержателям (retainer profiling), чтобы увидеть, какие функции/замыкания удерживают память.
- Минимизировать до малого воспроизводимого примера: заменять данные и размер, чтобы увидеть, при каком n (например $n$) начинается рост.
- Встроенные инструменты: +RTS -sstderr, threadscope/eventlog для конкурентных программ, библиотека weigher/ekg для runtime мониторинга.
Исправления (практические)
- Заменить ленивую свёртку на строгую: использовать `foldl'` из Data.List вместо `foldl`:
sumGood xs = foldl' (+) 0 xs
— это устраняет накопление вложенных thunk'ов.
- Принудительная строгость: `seq`, `deepseq` (для вложенных структур) или синтаксис BangPatterns (`!acc`) для аккумулирующих полей.
- Сделать поля структур строгими:
data S = S { a :: !Int, b :: !Foo }
- Избегать ненужного сохранения ссылки на входной список: не храните исходный список в замыканиях; используйте рекурсию с аккумулятором, строгую свёртку или итераторы.
- Если нужно потоковое/поэлементное потребление больших входов — использовать специализированные библиотеки: conduit, pipes, streaming, или strict ByteString/Vector; они дают контроль за памятью и не держат всё в памяти.
- Для lazy I/O: использовать явное чтение в чанках (strict ByteString) и закрывать ресурсы как можно раньше.
- При вставке в структуры (Map/Set/Seq) — использовать строгие версии операций или strict‑контейнеры, чтобы не накапливать нерешённые thunk'и внутри контейнера.
- Когда нужно проверить «полное» вычисление структуры (а не только верхнего уровня) — применять `deepseq` или `rnf` из Control.DeepSeq.
- Тестирование: добавляйте промежуточные `seq`/`evaluate`/`print` размеров (length/ByteString.length) чтобы локализовать место удержания.
Примерная отладочная последовательность
1. Свести программу к минимальному кейсу, где память растёт при увеличении входа (параметр $n$).
2. Посмотреть GC‑статистику (`+RTS -s`), понять: память постоянно растёт или только пиковая.
3. Включить heap‑профайлинг (GHC профайлер) — найти функцию/замыкание, удерживающие объекты.
4. Внести примерные правки (foldl' / ! поля / seq / deepseq / другой алгоритм) и снова профилировать — убедиться, что утечка ушла.
Короткие рецепты
- Сумма/агрегация по списку → использовать `foldl'`.
- Если вы храните промежуточные результаты без нужды → менять на потоковую обработку.
- Если структура содержит ленивые поля и растёт в памяти → делать поля строгими.
- Не доверяйте lazy IO для больших файлов; используйте стриминг или strict IO.
Если нужно, могу разобрать конкретный фрагмент вашего кода и показать, где именно вставить строгую семантику или заменить функцию — пришлите минимальный пример.