заметил я что если создать файл main.cpp c содержимым
#include "file1.cpp"
#include "file2.cpp"
#include "file3.cpp"
и скомпилировать его, то в моём случаи это в 5 раз быстрее, чем вызвать gcc file1.cpp file2.cpp file3.cpp. Файлов cpp у меня порядка 30-40.
Может у gcc есть такая опция, что-бы не создавать main.cpp. Т.е. что-бы он компилировал кучу cpp файлов как один большой ?
Таким способом размер бинарника иногда отличается в большую или меньшую сторону, по сравнению с обычной компиляцией. Не пойму пока почему так.
Здравствуйте, maks1180, Вы писали:
M>заметил я что если создать файл main.cpp c содержимым M>#include "file1.cpp" M>#include "file2.cpp" M>#include "file3.cpp" M>и скомпилировать его, то в моём случаи это в 5 раз быстрее, чем вызвать gcc file1.cpp file2.cpp file3.cpp.
Skip M>Не пойму пока почему так.
Потому что инклюды и все шаблоны в них обрабатываются один раз.
Можно и в сто раз ускориться.
M>то в моём случаи это в 5 раз быстрее
Чем больше лишних ненужных библиотек в заголовочных файлах используется, тем больше можно получить ускорения.
Правда надо сказать, что часто это не столько unity build сам по себе ускоряет компиляцию, а злоупотребление header-only библиотеками сильно её замедляет. А unity build лишь снижает их вред.
M>Может у gcc есть такая опция, что-бы не создавать main.cpp. Т.е. что-бы он компилировал кучу cpp файлов как один большой ?
Зачем такая опция в компиляторе, если проще сделать это в системе сборки? Всё равно там уже хранятся зависимости между файлами, и там же отслеживаются изменения в графе сборки, когда что-то поменялось и нужно составить список целей, которые надо пересобрать.
M>Таким способом размер бинарника иногда отличается в большую или меньшую сторону, по сравнению с обычной компиляцией. Не пойму пока почему так.
Так посмотри что там отличается :)
Например, эффекты unity build, влияющие на размер:
1. склеивание internal linkage функций/констант, которые почему-то имеют такой linkage, но используются в нескольких местах;
2. агрессивное встраивание, подобно lto;
3. невозможность удаления недостижимого кода/данных на уровне объектных файлов (если не используется -ffunction-sections и подобное)
Почему быстрее — примерно понятно (выше написали). Почему отличается размер — тоже понятно, появляется больше возможностей для inline.
Подобная практика обычно не применяется, ибо способна сломать код — например, static символы приобретут глобальную видимость, так что никаких стандартных средств в компиляторе для эмуляции такого поведения нет. Я рекомендую паралелльную компиляцию.
Здравствуйте, maks1180, Вы писали:
M>заметил я что если создать файл main.cpp c содержимым M>#include "file1.cpp" M>#include "file2.cpp" M>#include "file3.cpp" M>и скомпилировать его, то в моём случаи это в 5 раз быстрее, чем вызвать gcc file1.cpp file2.cpp file3.cpp. Файлов cpp у меня порядка 30-40. M>Может у gcc есть такая опция, что-бы не создавать main.cpp. Т.е. что-бы он компилировал кучу cpp файлов как один большой ?
gcc -include file1.cpp -include file2.cpp... -x c++ /dev/null
M>Таким способом размер бинарника иногда отличается в большую или меньшую сторону, по сравнению с обычной компиляцией. Не пойму пока почему так.
Это называется amalgamation. Используют, когда хотят упростить сборку (SQLite, например). А для ускорения сборки.. Наоборот, раньше компиляторам сносило крышу от больших размеров файлов исходников.
Здравствуйте, maks1180, Вы писали:
M>заметил я что если создать файл main.cpp c содержимым M>#include "file1.cpp" M>#include "file2.cpp" M>#include "file3.cpp" M>и скомпилировать его, то в моём случаи это в 5 раз быстрее, чем вызвать gcc file1.cpp file2.cpp file3.cpp. Файлов cpp у меня порядка 30-40. M>Может у gcc есть такая опция, что-бы не создавать main.cpp. Т.е. что-бы он компилировал кучу cpp файлов как один большой ? M>Таким способом размер бинарника иногда отличается в большую или меньшую сторону, по сравнению с обычной компиляцией. Не пойму пока почему так.
С другой стороны изменение одного файла повлечёт за собой полную пересборку всего.
К тому же собирая таким способом нужно учесть, чтобы в файлах внутренние классы и функции были с различными именами, проблема которой нет в случае разных файлов.
Тут надо смотреть какие плюсы перевешивают какие минусы
Здравствуйте, _NN_, Вы писали:
_NN>... _NN>Кстати, вы используете Предкомпилированные заголовочные файлы ? _NN>Это даёт существенное ускорение сборки при множестве файлов с повторяющимися инклудами.
Ну это как сказать. У нас в проекте достаточно много буста и стл. Для Clang время полной сборки с PCH примерно на 10-15% быстрее, для gcc примерно на 20% медленнее.
