время связывания профиля с gcc / g ++ и ld

Question

Я использую g ++ для компиляции и компоновки проекта, состоящего из примерно 15 исходных файлов c ++ и 4 общих объектных файлов. В последнее время время соединения более чем удвоилось, но у меня нет истории создания файла сборки. Есть ли способ профилировать g ++, чтобы увидеть, какая часть ссылок занимает много времени?

Редактировать: После того, как я заметил, что make-файл все время использует оптимизации -O3, мне удалось сократить время компоновки вдвое, просто удалив этот переключатель. Есть ли какой-нибудь хороший способ найти это без проб и ошибок?

Редактировать: Меня не интересует, как работает ld. Мне интересно знать, как можно сопоставить увеличение времени привязки к конкретным параметрам командной строки или объектным файлам.

Answer 1

Если вы только что достигли предела ОЗУ, вы, вероятно, сможете услышать, как работает диск, и монитор активности системы сообщит вам об этом. Но если связывание все еще связано с процессором (то есть, если загрузка процессора все еще высока), это не проблема. И если связывание связано с IO, наиболее распространенным виновником может быть информация времени выполнения. Взгляните на размер исполняемого файла в любом случае.

Чтобы ответить на вашу проблему по-другому: вы интенсивно используете шаблон? Для каждого использования шаблона с другим параметром типа создается новый экземпляр всего шаблона, поэтому вы получаете больше работы для компоновщика. Однако, чтобы сделать это на самом деле заметным, вам нужно использовать какую-то библиотеку, действительно перегруженную шаблонами. Многие из проекта Boost соответствуют требованиям - я получил раздувание кода на основе шаблонов при использовании Boost :: Spirit со сложной грамматикой. И ~ 4000 строк кода, скомпилированных до 7,7M исполняемого файла - при изменении одной строки удвоилось количество требуемых специализаций и размер конечного исполняемого файла. Впрочем, встраивание очень помогло, что привело к выходу 1,9 млн.

Совместно используемые библиотеки могут вызывать другие проблемы, вы можете посмотреть документацию на -fvisibility = hidden, и это в любом случае улучшит ваш код. Из руководства GCC по -видимости:

 Using this feature can very substantially
 improve linking and load times of shared object libraries, produce
 more optimized code, provide near-perfect API export and prevent
 symbol clashes.  It is *strongly* recommended that you use this in
 any shared objects you distribute.

Фактически, компоновщик обычно должен поддерживать возможность для приложения или для других библиотек переопределять символы, определенные в библиотеке, хотя обычно это не предназначенное использование. Обратите внимание, что использование этого не бесплатно, но требует (тривиальных) изменений кода.

Ссылка, предлагаемая документами: http://gcc.gnu.org/wiki/Visibility

Answer 2

Профилирование g++ окажется бесполезным, поскольку g++ не выполняет связывание, компоновщик ld выполняет.

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

Если ваше время ссылки заметно только с 15 файлами в ссылке, вероятно, что-то не так с вашей системой разработки [1]; либо у него есть диск, который находится в последних руках и постоянно повторяется, либо у вас недостаточно памяти для выполнения ссылки (ссылки часто требуют большого объема ОЗУ), и ваша система переходит как сумасшедшая.

Если вы работаете в системе на основе ELF, вы также можете попробовать новый компоновщик gold (часть binutils), который часто в несколько раз быстрее, чем GNU ld.

[1] Мои типичные ссылки включают 1000 объектов, производят исполняемые файлы размером более 200 МБ и заканчиваются менее чем за 60 секунд.

Answer 3

И gcc, и g ++ поддерживают подробный флаг -v, что позволяет им выводить подробности текущей задачи.

Если вы заинтересованы в реальном профилировании инструментов, вы можете проверить Sysprof или OProfile .