Скорость сборки проекта

[lapulya]

А, да. Собственно, мне случалось использовать это решение и не для шаблонов Когда требовалось резко снизить время на компиляцию-линковку.

Вад, не понимаю как можно резко снизить время на линковку и тем более на компиляцию делая инклуд cpp файла? По идее для компилятора нет никакой разницы какое расширение у файла, можно все писать в cpp, можно все писать в h файлах, нет никакой разницы кроме удобства (собственно поэтому и разделили).

[Вад]

Вад, не понимаю как можно резко снизить время на линковку и тем более на компиляцию делая инклуд cpp файла?

Если включить ряд .cpp-файлов в один общий и компилировать только его, то нужно будет слинковывать меньше модулей.

Время на компиляцию модулей уменьшается за счёт заголовков. Если включается куча заголовков, и компилятор не поддерживает прекомпиляцию заголовков (с чем мы столкнулись на одном gcc-кросс-компиляторе), то включение .cpp-файлов уменьшает количество вхождений одних и тех же заголовков в компилируемые модули. Особенно чувствительно при интенсивном использовании STL.
Прирост по скорости наблюдался на порядок, если не больше (по отдельности проект компилировался, может, минут 20-25, а вместе - минуты за 3).

[Алексей++]

Дык, с таким же успехом можно включать в cpp и "h" , если удаётся применить pimpl Стараюсь в последнее время так делать - если вспомогательный класс очень обособленный, то пимплю его, иначе он начинает светиться везде подряд. А у студии мозги тоже не резиновые ))

[Антон (LogRus)]

Алексей1153++, я полагаю Вад предлагает уменьшить число единиц трансляции, тем самым уменьшив работу препроцессора (иногда это самая дорогая часть) за счет, того что он не ищет по диску одни и теже хедеры по нескольку раз, а также уменьшая время линковки.
НО попытка выполнить такой финт ушами в MS VS может приводить к внутреннем ошибкам компилятора (очень он не любит сверх жирные файлы), правда в MS VS работают precompiled header поэтому проблема с длительной компиляцией из-за большого числа хедеров не так актуальна.

[Алексей++]

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

да не скажи... Хотя, в студии 9 у меня проект ещё не такой пухлый, поэтому не мог ещё оценить.
А в 6-й ощутимо - опечатку в КОММЕНТАРИЯХ в хедере подправишь - и снова 2 минуты компилить )). А когда дело происходит в cpp, перекомпилится быстро

[Антон (LogRus)]

А в 6-й ощутимо - опечатку в КОММЕНТАРИЯХ в хедере подправишь - и снова 2 минуты компилить )). А когда дело происходит в cpp,

Предполагаю  (только предполагаю на основе личного опыта ) причина в том, что твой хедер включается в слишком большое количество cpp, если это очень общих хедер нужный всем и вся и в каждом cpp, то это нормально, если же это хедер который используется в паре мест, то возможно он зря включен, в stdafx.h или некоторые из h и cpp

я в stdafx.h стараюсь включать хедеры, только внешних (по отношению к проекту) библиотек, в противном случае косметическая правка хедера приводит к перекомпиляции проекта

[Алексей++]

В том и дело, что это до офигения важный хедер, и распутать их вложение я даже не возьмусь сейчас - проект начинался на заре изучения с++, поэтому там вообще многое туманно )

[Антон (LogRus)]

Алексей1153++, тогда смирись

[Алексей++]

давно уж ) Радует только одно - что проект завершён, дока написана, и только изредка клиенты мелкие глюки приносят

[Вад]

Дык, с таким же успехом можно включать в cpp и "h" , если удаётся применить pimpl Стараюсь в последнее время так делать - если вспомогательный класс очень обособленный, то пимплю его, иначе он начинает светиться везде подряд. А у студии мозги тоже не резиновые ))

В том-то и дело, что если хедер "foo.h" включается в тучу .cpp-шников (какой-нибудь <vector> - частый гость, скажем), потому что он всем им нужен, то хоть он и не включается в ненужные, всё равно раз по 30 препроцессор его в каждый отдельный модуль при компиляции на инклуде запихнёт и обработает. А если всё компилируется слитком, то включится этот заголовок один раз.

Это вообще плохой подход с точки зрения распутывания зависимостей. Поэтому применялся только как неизбежное зло - всё-таки ждать по полчаса, пока проект соберётся, не всегда есть возможность. Особенно если в команде работают несколько человек, и правки вносятся и накапливаются очень быстро: два полных билда в день - и прощай час времени

[Алексей++]

Я тоже "за!" скорость компиляции, пусть это иногда заставляет произвести геморные движения. А то, пока компилится, либо уснёшь (гы, буквально было), либо мысль теряется.

[lapulya]

Странно мне это... у нас был проект (12 - 15 Мб исходников) некоторые модули которого использовали stl вдоль и поперек (в 85% всех h и cpp). Так вот полная сборка (с нуля) реально была долгой около 30 минут, но при изменении части h файлов проекта (cpp вообще почти не влияет на время сборки), ничего критичного не происходило, т.е. компиляция + сборка не более трех минут (ну есть конечно разные h файлы )))), но речь идет о тех, что не содержат интерфейсы или константы для всего проекта).

Прекомпайлед отключен (вообще всегда это Г отключаю), но компиляция + сборка идет менее 5 минут (речь не о ребилд ол, а об обычной сборке после внесения правок внесенных вами, такие сборки идут не реже раза в день, т.е. изменения ограничиваются вашими изменениями за 1 день). Если сборка идет дольше 5 минут, значит вы плохо спроектировали проект или делаете инклуды хеадеров в хеадеры где это не нужно (это нужно только при наследовании, использовании stl и, возможно, констант и перечислений)

[Алексей++]

А ещё ингда комп бывает не очень шустрый

[lapulya]

Вад, 2 полных билда в день???!!! ППЦ у вас проблемы... Зачем делать 2 полных билда в день? При любом количестве программистов абсолютно не нужно делать 2 полных билда (да ни одного не нужно). В проекте, о котором я упоминал, было около 15 человек программистов, полная сборка была 1 раз (возможно 2 раза) в неделю и в оооочень редких случаях (ну может раз в квартал были моменты) чаще.

Какой смысл в полной сборке 2 раза в день? При грамотной архитектуре и разделении зоны ответственности программистов за функциональные части проекта полная сборка нужна раз в неделю (и делать ее можно, когда вы уходите с работы, поставил собираться и домой, приходишь на следующий день и все готово, если не собралось, берешь тесак, разделочную доску и идешь к тому, в чьем коде проблемы, после того как яйца у подобных программистов заканчиваются, а это решается максимум в 2 захода, проблема решается, если яйца закончились, а проблема не решена, этого человека надо уволить).

[lapulya]

Алексей1153++, ну я не мог сказать что у меня был ураган))) но, и не полный отстой, такой очень средненький...

[Вад]

Дело не в проекте - для другой платформы сборка тех же самых исходников шла "менее 5 минут" Тут специфика компилятора. Вот только за давностью уже не вспомню, что ещё с ним было не так (собственно, билд-менеджментом не я занимался).

Насчёт 2х билдов в день. Прототип со сжатыми сроками. Нужно постоянно убеждаться, что всё работает с правками, которые внёс сосед. Разделение - разделением, но сосуществовать-то всё это будет вместе.

[Алексей++]

Лапуля, пипец - это твои методы воспитания программистов))
Уже команда евнухов ? )))

[lapulya]

Алексей1153++, если люде не понимают, что в систему контроля версий можно постить только 100% компилируемый код, то выходов 2 - или их надо или выгонять (ну если он и писать не умеет), или жестко наказывать (типа первое последнее китайское предупреждение и последнее последнее китайское предупреждение, больше не нужно, после 2 этих предупреждений их надо выгонять, в противном случае их ошибки очень дорого обходятся команде).

Если сборки идет раз в неделю (не дай бог чаще) + ребилд олл идет пол часа + 15 человек в команде + ошибка при сборке = около 8 часов в неделю в помойку.

[lapulya]

Вад, да какие бы сжатые сроки ни были (ну если только проект очень маленький, но в таком случае он и быстро собираться будет, даже при плохой архитектуре и разделении)... я даже больше скажу, я не постю в скв изменения чаще раза в день (обычно реже). Я должен быть убежден, что мой код работает и только потом его выкладываю (абсолютно также должен поступать каждый член команды).

Да, убеждаться что все работает с правками соседа должен тест (ну или сотрудник отдела тестирования), но не как не программист, да еще и с чужим для него кодом. Если интерфейс согласован, мой модуль работает корректно, то это не моя проблема! Это командная работа, каждый отвечает за свой кусок, есть проблемы - приходи поговорим (мы иногда всей комнатой, 5 - 6 человек, решали чью-то проблему, ну действительно ошибки были очень трудно отыскиваемыми)... Но если он считает, что у него проблем нет, т.е. все волшебно, то проблема работы его модутя это его проблемы, его ответственность.

[Алексей++]

lapulya, 30 минут (скажем, начался обед - запустили) это можно 2 раза в день А "вджобывать" все 8 часов в день, не отдыхая - так можно и хронически откидные копыта заработать

[Вад]

При команде в 15 человек я бы тоже не стал делать билд чаще раза в неделю. При команде в 3-4 человека ежедневные билды для прототипа считаю вполне допустимыми. Дело не в архитектуре, а в том, что нужно каждый день быть уверенным, что завтра всё можно быстро собрать в рабочую версию и иметь её как работающий промежуточный результат.

Поэтому я и не имел в виду, что код не компилируется. Разумеется, код выкладывали компилируемый, а в случае косяков виновник огребал по ушам. Нужно было, чтобы код работал. Да, у проекта были проблемы. Поскольку это было не конечной разработкой под ключ, никакого такого масштабного тестирования там практически не было. Ведь основное требование к прототипу - демонстрировать, что идея работоспособна. Что он и демонстрировал. Но поэтому следить за работоспособностью кода приходилось только через девелоперские тесты (если была возможность написать автономный тест) и пуск свежих билдов. 2 билда в день делались, конечно, не всегда Но если был срочно нужен свежий билд, ждать по полчаса - это как-то, по-моему, чересчур.

[lapulya]

Вад, Просто прототип обычно не очень пухлый, он именно как ты сказал делается как концепция продукта и я слабо себе представляю как он может 30 минут собираться (это тогда 100% проблема компилятора или железа), этож достаточно маленькое приложение, что ж там тогда столько времени занимает?