Как ускорить сборку?

gcc -pipe -j<число ядер процессора+1>

distcc + ccache

Ну и очевидно, что с -O0 сборка пройдёт быстрее.

возможно это поможет:

http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html

К вышеизложенному могу лишь порекомендовать пересмотреть граф зависимостей исходников. Ну и за чашкой кофе время пролетит незаметно.

PIMPL, время сборки с нуля не уменьшит, но все равно полезно

gcc -pipe -j<число ядер процессора+1>

Что делает -pipe? У мну одно ядро процессора.

distcc + ccache

Что это?

Ну и очевидно, что с -O0 сборка пройдёт быстрее.

А по дефолту разве не так?

Интересно. Хоть и куча ограничений.

Т.е. все хидеры boost и все мои неизменяющиеся хидеры проинклудить в отдельный файл, сделать его precompiled header и проинклудить в нужные файлы первой строкой?

Товарищ выше дал правильную ссылку про Precompiled headers. Глянь, должно помочь.

Т.е. все хидеры boost и все мои неизменяющиеся хидеры проинклудить в отдельный файл, сделать его precompiled header и проинклудить в нужные файлы первой строкой?

Свои хидеры наверное не стоит, они же погоды не делают. А в остальном все вроде так.

>boost
еще бы оно не тормозило

прекомпиленные заголовки буста (lambda, mpl и прочие) сами по себе по личному опыту сборку почти не ускоряют. прекомпилировать надо уже что-нибудь инстанциированноое (напр. extern template)

pimpl; меньше юзать бустовые шаблоны в заголовках, больше в реализации

прекомпиленные заголовки буста (lambda, mpl и прочие) сами по себе по личному опыту сборку почти не ускоряют.

Мну использует asio, serialization, алгоритмы для строк и самый тормозящий boost.cgi. В них вроде не особо много шаблонов.

в serialization думаю достаточно. он тянет mpl.

> -j<число ядер процессора+1>

А почему на единицу больше числа ядер?

Особенность шедулера процессов. В поиске подробнее.

Товарищ выше дал правильную ссылку про Precompiled headers. Глянь, должно помочь.

Чем они помогут в случае шаблонов?

2ТС: смирись, ничего особо не сделаешь. Пиши на лиспе :)

Вроде как с ccache иногда можно больно наступить на грабли?

Например?

1. Не использовать boost.

2. Не использовать C++.

3. Не использовать Си.

Все вышеперечисленные вещи страдают архитектурным изъяном негативно влияющим на возможную минимизацию времени сборки. А именно:

1. boost - оверюз шаблонов таким образом, каким их юзать и не предполагалось.

2. C++ - наличие недостаточно гибких по реализации шаблонов (смотрите как это можно реализовать в языке D). В самом языке кривая грамматика (контекстно-зависимая) и отсутствует система модулей. Из-за этого в частности приходится парсить много раз один и тот же код, а также отсутствует возможность качественно параллелизовать этот процесс.

3. Си - собственно этот тот язык из которого все растет. С++ просто остался максимально обратно совместимым с Си. Зло нужно искоренять.

Для вышеперечисленных проблем существуют различные костыли: PCH, ccache, distcc. Когда-то они помогают, но существенно ничего не меняется.

Серьезно.. начните отказываться от (1), (2) и (3) уже сегодня.

И тем не менее после того, как я заюзал PCH, время полной пересборки уменьшилось с 12 минут до 8.

PS. Выяснилось, что больше всего на время сборки влияет именно boost.cgi.

>gcc -pipe -j<число ядер процессора+1>

Что за бред?

Хз, в хэндбуке об этом упоминалось.

А что не так?

> Все вышеперечисленные вещи страдают архитектурным изъяном негативно влияющим на возможную минимизацию времени сборки

3. Си - собственно этот тот язык из которого все растет

Откуда такой бред? Где архитектурные изъяны языка Си, влиящие на время сборки?

>использует кучу библиотек boost

ССЗБ

>А что не так?

Откуда в gcc ключ "-jN"?

А, точно, по инерции не заметил.

distcc + ccache распараллеливает, можно задействовать несколько компьютеров. -j3 в случае использования двух ядер распараллеливает задачу на имеющихся в процессоре компьютерах. Смысла ставить число после j чем количества ядер мало. Но количество ядер, и ещё плюс один, скорость сборки всё же немного увеличит. Не спрашивай почему, я не знаю

немного уточню, distcc распараллеливает процесс сборки между хостами
ccache использует кэш предыдущих сборок, учитываются соответствия исходных файлов, флаги компиляции и собственно сам компилятор. Проблемы с ccache возможны только в случае неисправного железа.
-j2 может ускорить процесс на одноядерном проце. Пока один сишник переводится в объектный файл, второй подгружается с диска, это устранит простои процессора в случае небольших исходников(возможно, сочиняю).
-pipe - передаёт результаты сборки не через файл на диске, а через конвейер, то бишь, через оперативную память.

Спасибо! И вкратце, и понятно. Ещё хорошо помогает сбрка вообще без оптимизаций (-O0) и отключение дебаггерской информации. В первом ответе всё перечислено! Я просто хотел разъяснить подробнее

Откуда такой бред? Где архитектурные изъяны языка Си, влиящие на время сборки?

У C один, но огромный архитектурный изъян. Это необходимость в толстом проекте по миллион раз перекомпиливать одно и то же (хидеры). Но в C эту проблему частично решают precompiled headers.

Этот изъян в полной мере унаследован C++. Но в нем прибавились еще и шаблоны, которые прекомпилировать бесполезно.

Да, нужно завязывать с ДТ.