#включать все.cpp файлы в один блок компиляции?
недавно у меня была причина работать с некоторыми проектами Visual Studio C++ с обычными конфигурациями отладки и выпуска, но также "Release All" и "Debug All", которые я никогда раньше не видел.
оказывается у автора проектов есть единое все.СРР, который #включает в себя все остальные .cpp-файлы. * Все конфигурации просто построить это все.файл cpp. Он, конечно, исключен из обычных конфигураций, а обычные конфигурации не строят все.cpp
I просто интересно, было ли это обычной практикой? Какую пользу это приносит? (Моей первой реакцией было то, что он плохо пахнет.)
какие подводные камни вы, вероятно, столкнуться с этим? Один из них я могу придумать, если у вас есть анонимные пространства имен в вашем .cpps, они больше не являются "частными" для этого cpp, но теперь видны и в других cpps?
все проекты строят библиотеки DLL, поэтому иметь данные в анонимных пространствах имен не было бы хорошей идеей, не так ли? Но функции были бы Хорошо?
Ура.
5 ответов:
он упоминается некоторыми (и google-able) как "Unity Build". Он связывает безумно быстро и компилирует достаточно быстро. Он отлично подходит для сборок, которые вам не нужно повторять, как сборка выпуска с центрального сервера, но это не обязательно для инкрементного построения.
и это Пита для поддержания.
EDIT: вот первая ссылка google для получения дополнительной информации:http://buffered.io/posts/the-magic-of-unity-builds/
то, что ускоряет это то, что компилятору нужно только прочитать все один раз, скомпилировать, а затем связать, а не делать это для каждого .файл cpp.
Брюс Доусон имеет гораздо лучше написать об этом в своем блоге: http://randomascii.wordpress.com/2014/03/22/make-vc-compiles-fast-through-parallel-compilation/
Unity создает улучшенные скорости сборки по трем основным причинам. Первая причина заключается в том, что все общие заголовочные файлы должны быть проанализированы только один раз. Многие проекты C++ имеют много заголовочных файлов, которые включены большинством или всеми файлами CPP, и избыточный разбор этих файлов является основной стоимостью компиляции, особенно если у вас много коротких исходных файлов. Предварительно скомпилированные заголовочные файлы могут помочь с этой стоимостью, но обычно есть много заголовочных файлов, которые не являются предварительно скомпилированный.
следующая основная причина, по которой сборки unity улучшают скорость сборки, заключается в том, что компилятор вызывается меньше раз. Существует некоторая стоимость запуска с вызовом компилятора.
наконец, сокращение избыточного разбора заголовков означает сокращение избыточного кода для встроенных функций, поэтому общий размер объектных файлов меньше, что делает связывание быстрее.
Unity сборки также могут дать лучший код-gen.
единство построения не быстрее из-за уменьшения дискового ввода/О. У меня профилированного много строит программе xperf и я знаю о чем я говорю. Если у вас достаточно памяти, то дисковый кэш ОС будет избегать избыточного ввода - вывода-последующие чтения заголовка будут поступать из дискового кэша ОС. Если у вас недостаточно памяти, то сборки unity могут даже ухудшить время сборки, заставив объем памяти компилятора превысить доступную память и получить выгрузку.
дисковый ввод-вывод стоит дорого, что вот почему все операционные системы агрессивно кэшируют данные, чтобы избежать избыточного дискового ввода-вывода
интересно, если это все.cpp пытается поместить весь проект в одну единицу компиляции, чтобы улучшить способность компилятора оптимизировать программу по размеру?
обычно некоторые оптимизации выполняются только в отдельных единицах компиляции, такие как удаление дубликатов кода и подстановкой.
тем не менее, я, кажется, помню, что последние компиляторы (Microsoft, Intel, но я не думаю, что это включает GCC) могут выполнять эту оптимизацию по всему миру несколько единиц компиляции, поэтому я подозреваю, что этот "трюк" излишен.
тем не менее, было бы любопытно посмотреть, действительно ли есть какая-либо разница.
Я согласен с Брюсом; из моего опыта я попытался реализовать Unity Build для одного из моих .dll проекты, которые имели тонну заголовка включает в себя и много .cpps; чтобы снизить общее время компиляции на VS2010(уже исчерпал Дополнительные параметры сборки), но вместо того, чтобы сократить время компиляции, у меня закончилась память, и сборка даже не смогла завершить компиляцию.
однако добавить; я нашел включение многопроцессорной компиляции опция в Visual Studio довольно помогает сократить время компиляции; я не уверен, что такая опция доступна в других компиляторах платформы.
в дополнение к Брюсу Доусону отличный ответ следующая ссылка дает больше информации о плюсах и минусах unity builds -https://github.com/onqtam/ucm#unity-builds