Сокращение объема памяти большой незнакомой кодовой базы

Question

Предположим, у вас довольно большое (~ 2,2 MLOC), довольно старое (запущенное более 10 лет назад) настольное приложение Windows на C / C ++. Около 10% модулей являются внешними и не имеют источников, только символы отладки.

Как бы вы сократили объем памяти приложения наполовину? По крайней мере, что бы вы сделали, чтобы узнать, где используется память?

Answer 1

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

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

Answer 2

это описание / скелет приложения трассировки памяти, которое я использовал, чтобы снизить потребление памяти нашей игрой на 20%. Это помогло мне отследить многие распределения, сделанные внешними модулями.

Answer 3

Это не простая задача. Начните с поиска любых утечек памяти, которые вы обнаружите (хорошим инструментом будет Rational Purify ). Просмотрите исходный код и попробуйте оптимизировать структуры данных и / или алгоритмы.
Извините, если это звучит пессимистично, но сокращение использования памяти на 50% не звучит реалистично.

Answer 4

Существует вероятность того, что вы сможете быстро обнаружить некоторые существенные недостатки. Сначала вы должны проверить, для чего используется память. Инструмент, который я нашел очень удобным для этого, - Memory Validator

Как только у вас появится эта «карта использования памяти», вы можете проверить, нет ли висячих фруктов. Существуют ли какие-либо структуры данных, занимающие много памяти, которые могут быть представлены в более компактной форме? Это часто возможно, особенно когда доступ к данным хорошо инкапсулирован и когда у вас есть запасная мощность процессора, вы можете посвятить сжатие / распаковку их при каждом доступе.

Answer 5

Одним из инструментов для анализа использования памяти является LeakDiag, доступный для бесплатной загрузки с Microsoft . По-видимому, он позволяет подключить все распределители пользовательского режима к VirtualAlloc и в любое время выгружать снимки выделения процессов в XML. Эти моментальные снимки затем можно использовать для определения того, какие стеки вызовов выделяют большую часть памяти, а какие стеки вызовов просачиваются. В нем отсутствует симпатичный интерфейс для анализа снимков (если только вы не можете получить LDParser / LDGrapher через службу поддержки Microsoft Premier), но все данные есть.

Еще одна вещь, на которую стоит обратить внимание, это то, что у вас могут быть ложные срабатывания утечки из распределителя BSTR из-за кэширования, см. «Привет, почему я передаю все мои BSTR?»

Answer 6

Первые места для меня будут:

Делает ли приложение много памяти для предварительного распределения, чтобы использовать ее позже? Часто ли эта память остается неиспользованной, никогда не раздаваемой? Подумайте о переходе на новое / удаление (или лучше используйте smart_ptr) по мере необходимости.

Использует ли код статический массив, такой как

Object arrayOfObjs[MAX_THAT_WILL_EVER_BE_USED];

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

Answer 7

Не думаю, что ваш вопрос поставлен правильно.

Размер исходного кода напрямую не связан с объемом памяти. Конечно, скомпилированный код будет занимать некоторую память, но приложение может иметь собственные требования к памяти. И статические (переменные, объявленные в коде) и динамические (объект, создаваемый приложением).

Я бы предложил вам профилировать выполнение программы и внимательно изучить код.