avva | программистское: о памяти

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

Memory leaks are the least of your problems in a compiler; it's not like it's a long running process. You run it, it terminates, the OS cleans up for you.
I did some work on SDCC years ago and it went through a brief "lets use a garbage collector!" phase until everybody realized it was contributing negative value. It was more efficient to simply free memory where convenient and leak it where not.

... и дальше:

I believe it's well known that compilers leak memory like sieves. But the thing is, it doesn't really matter in most contexts. If the leak is linear with the size of the program you're probably fine and no one will notice anyway.

(кстати, всю эту дискуссию о компиляторах стоит проглядеть: там есть немало отличных ссылок)

Это очень полезный совет: иногда в языке и среде, которые казалось бы требуют тщательной работы с malloc()/free() или их эквивалентами, про free() можно просто забыть и не делать, если программа выполняется быстро и не требует очень много памяти. Полезный потому, что привыкший к тщательной дисциплине программист может об этом просто не подумать.

Но мне это напомнило еще вот какую давнюю мысль: по-моему, намного реже, чем следовало бы, программисты на языках с эксплицитной обработкой памяти пользуются отдельными кучами. "Отдельная куча" (private heap) означает всего лишь возможность отводить память в отдельном месте, идентифицируемом каким-то ключом. Например, в Win32 есть функции: HeapCreate() создает новую кучу и возвращает идентификатор, HeapAlloc() - вместе с желаемым размером получает идентификатор кучи и отводит память именно в ней, HeapFree() - очевидно, и HeapDestroy() - удалить всю кучу вместе со всей памятью в ней, которой еще не сделали HeapFree().

Иногда это называют не кучей, а "ареной", но суть та же. На самом деле самое главное во всем этом - возможность удалить кучу одним махом, потому что если она есть, и если вся память, что отводится из кучи, вместе не слишком велика, то отдельно освобождать ничего не надо. Собственно, можно обойтись без free() вообще. Куча тогда превращается в сплошной кусок памяти (или связанный список таких кускок, если надо), а malloc() становится тривиальным, он просто двигает указатель на свободную часть кучи.

Очень часто значительная часть логики программы устроена так. Начинаем строить какой-то объект (в C это может быть сложная структура, неважно), он в свою очередь создает и инициализирует другие объекты внутри себя, или целые массивы, или списки, или еще что, неважно. Все это по цепочке вложено друг в друга, а после создания еще начинает как-то работать и двигаться вместе, вызывать друг друга, хранить какую-то информацию итд. В конце концов объект выполнил свое дело и удаляется, по цепочке вначале удаляя все вложенные объекты и контейнеры и освобождая всю память. Все это делается через сложный танец new/delete или malloc/free. Но если вся память, что нужна объекту и всему, что в него вложено, не слишком велика на протяжении его жизни, то с помощью отдельной кучи только для этого объекта и всего, что в него вложено, можно избежать всего этого сложного танца и сделать код одновременно намного проще, лучше защищенным от ошибок и даже быстрее - да-да, быстрее, чем обычный танец malloc/free. Единственное, чем платишь - повышенным расходом памяти во время жизни объекта, да и то часто налог этот весьма невелик.

Я уже лет десять как не пишу под Windows, но до сих пор помню, какими полезными и правильными были функции для работы с отдельными кучами. Конечно, каждый может сам на коленке сколотить что-то свое для этого; я не раз такое встречал, да и сам несколько раз писал. Но все же меня удивляет, что в Юниксе нет стандартного интерфейса для этого дела. И я не раз видел исходники библиотек или приложений, которые бы этот простой прием сильно упростил и улучшил.

Flat | Top-Level Comments Only

From:

http://users.livejournal.com/_navi_/

А чем конкретно полезно это специфичное WinAPI для использования арен? Тем, что за тебя уже определён какой-то кастомный HeapAlloc, который наверняка содержит в себе что-то лишнее для данной проблемы, как минимум работу с фри-листами (вместо того, чтобы дать программисту возможность задать оптимальный алгоритм аллокации для арены)?

From:

avva.livejournal.com

Полезно в первую очередь тем, что оно есть и стандартное, и тем самым привлекает внимание программиста, становится частью его стандартного арсенала итд.

То, что HeapAlloc() использует свой конкретный алгоритм, и в частности не так быстр, как, например, алгоритм сплошной аллокации без освобождения - в 99.99% случаев абсолютно неважно и никакой роли не играет. Давайте не забывать слова Кнута о преждевременной оптимизации.

(...)

программистское: о памяти

Page Summary

Style Credit

Expand Cut Tags