Я ищу инструмент для упрощения анализа файла карты компоновщика для большого проекта C ++ (VC6).
Во время обслуживания двоичные файлы неуклонно растут, и я хочу выяснить, откуда они взялись. Я подозреваю, что в библиотеке, совместно используемой разными DLL, чрезмерное расширение шаблонов, но простое подписание файла карты не дает нам никаких оснований.
Какие-либо предложения?
Это замечательный инструмент для анализа / проводника / просмотра файлов карты, созданный компилятором. Проверьте, можете ли вы изучить файл карты, созданный gcc.
amap: инструмент для анализа файлов .MAP, созданных 32-разрядным компилятором Visual Studio, и отчета об объеме памяти, используемой данными и кодом. Это приложение также может читать и анализировать файлы MAP, созданные компиляторами Xbox360, Wii и PS3.
Файл карты должен иметь размер каждого раздела, вы можете написать быстрый инструмент для сортировки символов по этому размеру. Также есть инструмент командной строки, который поставляется с MSVC (undname.exe), который вы можете использовать для распутывания символов.
После того, как у вас есть символы, отсортированные по размеру, вы можете создавать их еженедельно или ежедневно по своему усмотрению и сравнивать, как размер каждого символа менялся с течением времени.
Сам по себе файл карты из любой отдельной сборки может мало что сказать, но исторический отчет о скомпилированных файлах карты может сказать вам довольно много.
Вы пробовали использовать dumpbin.exe для своих файлов .obj?
Что искать:
Если что-либо из вышеперечисленного относится к вам. Проверьте, широко ли они видны, т. Е. Используются / видны ли они в больших частях вашего приложения.
Нет предложений по инструменту, но есть предположение относительно возможной причины: включено ли у вас добавочное связывание? Это может вызвать расширение во время последующих сборок ...
Компоновщик удалит неиспользуемые символы, если вы компилируете с / opt: ref, поэтому, если вы используете это и не используете инкрементное связывание, я бы ожидал, что расширение двоичных файлов будет только результатом добавления фактического нового кода. Насколько я знаю ... надеюсь, это немного поможет.
Шаблоны, макросы и STL в целом занимают очень много места. Объявленный большой универсальной библиотекой, BOOST добавляет много места проектам. BOOST_FOR_EACH - пример этого. Это сотни строк шаблонного кода, которых можно было бы просто избежать, написав правильный дескриптор цикла, который, как правило, представляет собой всего лишь несколько дополнительных нажатий клавиш.
Получите Visual AssistX, чтобы не печатать, а не использовать шаблоны. Также подумайте о том, чтобы владеть кодом, который вы используете. Макросы и расширение встроенных функций не обязательно будут отображаться.
Кроме того, если вы можете, отойдите от архитектуры DLL к статическому связыванию всего в один исполняемый файл, который работает в разных «режимах». Нет абсолютно ничего плохого в том, чтобы использовать один и тот же исполняемый образ столько раз, сколько вы хотите, просто передав другой параметр командной строки в зависимости от того, что вы хотите, чтобы он делал.
DLL являются худшим виновником потери места и замедления времени выполнения проекта. Люди думают, что они экономят место, хотя на самом деле они имеют противоположный эффект, иногда увеличивая размер проекта в десять раз! Плюс они увеличивают свопинг. Используйте фиксированные разделы кода (без раздела перемещения) для повышения производительности.
