Что такое с ++ компиляция горлышка производительности?

Question

Когда я делаю новую компиляцию для своего проекта, которая включает в себя 10+ библиотек с открытым исходным кодом. Это займет около 40 минут. (на обычном оборудовании)

Вопрос: где на самом деле мои горлышки? поиск жесткого диска или процессор Ghz? Я не думаю, что многоядерный поможет много исправить?

- Правка 1 -
мое обычное оборудование = i3 oc до 4,0 ГГц, 8 ГБ 1600 МГц DDR3 и 2 ТБ Western digital

- Правка 2 -
мой код = 10%, libs = 90%, я знаю, что мне не нужно все время собирать, но я хотел бы узнать, как улучшить производительность компиляции, поэтому, покупая новый компьютер для разработчика, я бы сделал более разумный выбор.

- Правка 3 -
cc = Visual Studio (черт)

Answer 1

40 минут для сборки наиболее вероятно (фактически, через 40 минут я бы сказал, что определенно близко), вызванное плохим использованием #include. Вы включаете вещи, которые не нужно включать, им могут потребоваться только предварительные декларации.

Уборка вашего кода приведет к ОГРОМНЫМ различиям. Я знаю, что это много работы, но вы будете удивлены. В одной компании, в которой я работал в библиотеке, сборка которой заняла более 30 минут, была оптимизирована до трехминутной сборки всего за неделю, убедившись, что все #include были необходимы, и добавив предварительные объявления вместо #includeing. В этой библиотеке было более миллиона строк кода, чтобы дать вам представление ...

Answer 2

Вы не правы, многоядерный процессор обеспечивает огромное ускорение вплоть до момента, когда ваш жесткий диск фактически отказывается:)

Доказательство на примере: distcc ,который приносит распределенные сборки (моя сборка использует около 20 ядер параллельно, фактически она связана с локальной фазой предварительной обработки).

Что касается настоящего узкого места, то оно имеет отношение к механизму #include.Языки с модулями компилируются гораздо быстрее ...

Answer 3

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

вам придется анализировать свои проекты и время, затрачиваемое на каждом этапе, чтобы определить узкие места.

в типичных больших проектах на c ++ процесс обычно связан с процессором, а затем с диском.если все наоборот, вы, вероятно, в аду зависимости заголовка.

на самом деле существует масса способов уменьшить время компиляции и зависимость в ваших проектах.Лучшее единственное упоминание, которое я знаю, написано Лакосом:

http://www.amazon.com/Large-Scale-Software-Design-John-Lakos/dp/0201633620/ref=sr_1_1?ie=UTF8&qid=1296569079&sr=8-1

Это одна из самых важных / практических книг по С ++, которые я читал.значительно сократить время компиляции (например, более чем в 40 раз быстрее, если вы относитесь к нему серьезно), но может потребоваться много работы / времени для исправления существующих кодовых баз.

Answer 4

Начиная с VS 2010, VS может при желании использовать несколько ядер при компиляции одного проекта. Он также может компилировать несколько проектов параллельно. Однако в моем опыте параллельное ускорение не кажется значительным: например, Xcode намного лучше выполняет параллельные сборки.

К счастью, вам не нужно каждый раз перестраивать библиотеки с открытым исходным кодом, верно? Вы можете собрать их один раз, сохранить файлы .lib в системе управления версиями и использовать их для последующих сборок.

Вы пробовали предварительно скомпилированные заголовочные файлы для своего собственного кода? Это может привести к значительному ускорению.

Answer 5

Когда вы компилируете с нуля, да, это займет больше времени.Используйте 40-летнюю технологию make, которую VS включает в качестве управления проектами, для компиляции только того, что должно быть скомпилировано после первого запуска.

При этом модель модуля перевода C ++ плюс широкое использование шаблонов может бытьзначительная практическая проблема.