Каковы некоторые методы или инструменты для профилирования чрезмерного размера кода в приложениях C/C++?
используйте 3 нотации части и псевдоним до таблицы, пример
select * from tempdb.dbo.sysobjects a
join master.dbo.sysobjects b on a.id = b.id
3 ответа
Если вы хотите узнать, что помещается в ваш исполняемый файл, спросите свои инструменты. Включите параметр --print-map (или -M) компоновщика ld, чтобы создать файл карты, показывающий, что он поместил в память и где. Выполнение этого для примера со статической связью, вероятно, более информативно.
Если вы не вызываете ld напрямую, а только через командную строку gcc, вы можете передать ld определенные параметры ld из командной строки gcc, поставив перед ними -W1, .
Один из очень грубых, но очень быстрых методов - чтобы посмотреть размер ваших объектных файлов. Не весь код в объектных файлах будет скомпилирован в окончательный двоичный файл, поэтому может быть несколько ложных срабатываний, но это может дать хорошее представление о том, где будут находиться горячие точки. Найдя самые большие объектные файлы, вы можете вникнуть в них с помощью таких инструментов, как objdump и nm .
В Linux компоновщик действительно объединяет несколько экземпляров шаблонов.
Убедитесь, что вы не измеряете двоичные файлы отладки (отладочная информация может занимать более 75% окончательного двоичного размера).
Один из способов уменьшить окончательный размер двоичного файла - это скомпилировать с помощью -ffunction-section и -fdata-section , а затем связать с -Wl, - gc-section .
Еще большее сокращение (мы видели 25%) может быть возможно, если вы используете разрабатываемую версию [gold] [1] (новый линкер только для ELF, часть binutils ) и связать с -Wl, - icf
Другой полезный метод - сокращение набора символов, которые «экспортируются» вашими разделяемыми библиотеками (все экспортируется по умолчанию), либо через __ attribute __ ( (видимость (...))) , или с помощью скрипта компоновщика.Подробности здесь (см. «Экспортный контроль»).