Анализ файла MAP - откуда мой размер кода? - PullRequest
9 голосов
/ 23 февраля 2009

Я ищу инструмент для упрощения анализа файла карты компоновщика для большого проекта C ++ (VC6).

Во время обслуживания двоичные файлы неуклонно растут, и я хочу выяснить, откуда они берутся. Я подозреваю какое-то чрезмерное расширение шаблона в библиотеке, совместно используемой разными DLL, но jsut browsign файл карты не дает хороших подсказок.

Есть предложения?

Ответы [ 5 ]

7 голосов
/ 19 сентября 2012

Это - замечательный инструмент для анализа, анализа и просмотра файлов карт, созданный компилятором. Проверьте, можете ли вы изучить созданный gcc файл карты.

amap: инструмент для анализа файлов .MAP, созданных 32-разрядным компилятором Visual Studio, и отчета об объеме используемой памяти данными и кодом Это приложение также может читать и анализировать файлы MAP, созданные компиляторами Xbox360, Wii и PS3.

2 голосов
/ 23 февраля 2009

Файл карты должен иметь размер каждого раздела, вы можете написать быстрый инструмент для сортировки символов по этому размеру. Есть также инструмент командной строки, который поставляется с MSVC (undname.exe), который вы можете использовать для разбора символов.

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

Один файл карты из какой-либо отдельной сборки может ничего не сказать, но исторический отчет о файлах скомпилированной карты может рассказать вам совсем немного.

2 голосов
/ 14 июня 2009

Вы пытались использовать dumpbin.exe в своих файлах .obj?

Материал для поиска:

  • Используете много STL?
  • Много классов C ++ с встроенными методами?
  • Много констант?

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

1 голос
/ 23 февраля 2009

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

Компоновщик удалит неиспользуемые символы, если вы компилируете с / opt: ref, так что если вы используете это и не используете инкрементное связывание, я ожидаю, что расширение двоичных файлов будет только результатом фактического нового кода добавлено. Насколько я знаю ... надеюсь, это немного поможет.

0 голосов
/ 16 декабря 2010

Шаблоны, макросы, STL в общем - все занимают огромное количество места. Обозначенная как отличная универсальная библиотека, BOOST добавляет много места для проектов. BOOST_FOR_EACH является примером этого. Это сотни строк шаблонного кода, которых можно было бы просто избежать, написав правильный дескриптор цикла, который, как правило, всего несколько нажатий клавиш.

Получите Visual AssistX для сохранения набора текста без использования шаблонов. Также подумайте о владении кодом, который вы используете. Макросы и расширение встроенных функций не обязательно будут отображаться.

Также, если вы можете, перейдите от архитектуры DLL к статическому связыванию всего в один исполняемый файл, который работает в разных «режимах». Нет абсолютно ничего плохого в том, чтобы использовать один и тот же исполняемый образ столько раз, сколько вы хотите, просто передавая другой параметр командной строки в зависимости от того, что вы хотите, чтобы он делал.

Библиотеки DLL являются худшим виновником потери пространства и замедления времени выполнения проекта. Люди думают, что они экономят пространство, хотя на самом деле они имеют противоположный эффект, иногда увеличивая размер проекта в десять раз! Плюс они увеличивают обмен. Используйте фиксированные секции кода (без секции перемещения) для производительности.

...