На чём может основываться выбор момента времени освобождения выделенной памяти, когда объект уже гарантированно не понадобится в языке C?
Конкретного кода к вопросу у меня нет, поскольку затрагиваемая тема относится по существу ко всем программам на C. Интересует в первую очередь стратегия и принципы вызова встроенной функции free и подготовка к её вызову, такая, как например, хранение всех переменных в одном объекте или использование переменных static в максимуме случаев. Например, Gigachat мне предлагает освобождать ресурсы сразу после использования, но мне кажется это не единственное возможное решение, так?
Ответы (2 шт):
Нужно учитывать особенности платформы и как же выделяется память. Стоимость высвобождения памяти тоже надо учитывать и, возможно, повторно использовать выделенную память. Эти операции зачастую имеют недетерминированную продолжительность, напрямую не связанную с запрашиваемым объемом памяти.
В общем случае есть три подхода:
- Выделять как можно позже, перевыделять только уж если очень нужно, высвобождать как можно раньше.
- Выделить запланированное количество памяти в начале работы, высвободить в конце работы процедуры или приложения в целом, это как получится. Повторно использовать уже выделенную память. В Си это проще оформить чем в более абстрагированном Си++ благодаря определению понятия "объекта" как области памяти размером X в которой может храниться значения любого типа размером не больше X. Это очень популярный подход в режиме реального времени.
- Реализовать аналог RAII. Обычно это случается там где уже разработчик начинает применять парадигмы ООП в языке без оного. В принципе, это вариант первого подхода, только абстрагированный от каждой конкретной задачи, позволяет в упрощенной форме определить когда же мы можем позволить себе высвободить память. И да, такое случается и известно как "Си с классами", большие и очень известные системы написаны с использование подобных структур.
Начните с двух правил:
Выделяйте память когда она стала нужна, не раньше.
Возвращайте память когда она стала не нужна, не позже.
Если вы, применяя эти два правила, получили неудовлетворительную производительность и профилировщик подтвердил, что проблема в управлении памятью, то читайте продвинутые статьи по управлению памятью и приходите сюда с конкретными вопросами.
P.S. Я не верю что вы в ближайшее время упрётесь в ограничения производительности менеджера памяти. Большинство программистов на С никогда не заходили так далеко. Менеджер памяти в С один из самых простых и быстрых. Загнать его ой как нелегко.