Инструмент GNU для анализа и сокращения времени компиляции для моего приложения - PullRequest
4 голосов
/ 01 октября 2010


Я использую SUSE10 (64 бит) / AIX (5.1) и HP I64 (11.3) для компиляции моего приложения.Просто для справки, мое приложение имеет около 200KLOC (2Lacs) строк кода (без шаблонов).Это чисто C ++ код.Из измерений я вижу, что время компиляции колеблется от 45 минут (SUSE) до около 75 минут (AIX).

Вопрос 1: Это время нормально (приемлемо)?

Вопрос 2: Я хочу изменить структуру кода и сократить время компиляции.Есть ли инструмент GNU, который может помочь мне сделать это?

PS:
a.Большая часть вопроса в stackoverflow была связана с Visual Studio, поэтому мне пришлось опубликовать отдельный вопрос.
b.Я использую версию gcc 4.1.2.
c.Другая информация (которая может быть полезна) - это то, что код распространяется по 130 файлам .cpp, но распределение кода варьируется от 1KLOC до 8 KLOCK в файле.

Заранее спасибо за помощь !!!

Редактировать 1 (после комментариев)
@PaulR "Вы используете для этого make-файлы? Всегда ли вы делаетеполная (чистая) сборка или просто инкрементная сборка? "
Да, мы используем make-файлы для сборки проекта.
Иногда мы вынуждены делать полную сборку (например, ночная сборка / запуск или автоматический запуск или обновлениеполный код, так как многие члены изменили много файлов).Так что я выложил в общем смысле.

Ответы [ 7 ]

3 голосов
/ 01 октября 2010

Прочтите Крупномасштабный дизайн C ++ Джона Лакоса , чтобы узнать о некоторых очень хороших методах анализа и реорганизации структуры проекта для минимизации зависимостей.В конечном итоге время, затрачиваемое на создание большого проекта, увеличивается как по мере увеличения объема кода, так и по мере увеличения зависимостей (или, по крайней мере, влияние изменений в заголовочных файлах увеличивается по мере увеличения зависимостей).Таким образом, минимизация этих зависимостей - одна из целей.Концепция Lakos Levelization очень полезна при разработке способов разделения нескольких больших монолотных взаимозависимых библиотек на нечто с гораздо лучшей структурой.

3 голосов
/ 01 октября 2010

Чрезмерное (или, казалось бы, чрезмерное) время компиляции часто вызвано слишком сложной иерархией включаемых файлов.

Хотя это не совсем инструмент для этой цели, doxygen может быть весьма полезен: среди других диаграмм он может отображать иерархию включаемых файлов для каждого исходного файла в проекте. Я нашел много интересных и запутанных зависимостей в моих проектах.

2 голосов
/ 01 октября 2010

Длительное время компиляции в больших проектах C ++ почти всегда вызвано неправильным использованием заголовочных файлов. Раздел 9.3.2 из Язык программирования C ++ предоставляет несколько полезных моментов. Предварительная компиляция заголовочных файлов может значительно сократить время компиляции больших проектов. Для получения дополнительной информации см. Документацию GNU по предварительно скомпилированным заголовкам .

2 голосов
/ 01 октября 2010

В дополнение к уже упомянутому ccache, взгляните на distcc . Бросить больше оборудования для решения такой масштабируемой проблемы дешево и просто.

2 голосов
/ 01 октября 2010

Я не могу ответить на ваши конкретные вопросы, но я использую ccache , чтобы помочь со временем компиляции, который кэширует объектные файлы и будет использовать те же самые, если исходные файлы не изменятся. Если вы используете SuSE, он должен прилагаться к вашему дистрибутиву.

1 голос
/ 01 октября 2010

Убедитесь, что ваши основные цели создания могут выполняться параллельно (make -j <CPU_COUNT+1>) и, конечно, попробуйте использовать ccache . Кроме того, мы экспериментировали с дисками ccache и RAM, если вы экспортируете CCACHE_DIR и указываете его на RAM-диск, это также ускорит процесс компиляции.

0 голосов
/ 01 октября 2010

Если вы используете для этого рекурсивные make-файлы, вы можете подумать о переключении на нерекурсивный make-файл, который должен быть намного быстрее.Больше информации о этом вопросе о стеке и статье OSDev wiki о make-файлах .

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...