Комментарии 9
Результаты огонь.
Интересно было бы услышать почему для раскатки окружения (как я понял) используется не докер, или хотя бы отдельная репа хоть через сабмодули.
Кажется что проблема веса репозитория тут будет основной со временем + все более тяжелая его прокачка по сети (хотя решается взятием не всей истории). Ну и гипотетический переход на другие платформы будет сопряжен с тасканием зоопарка бинарников в репо для кода, хотя казалось бы что этого можно не делать.
Понятно что текущий подход по хранению окружения выглядит максимально простым, хоть и входит в некоторые противоречия с общими практиками, но каких-то сильных контраргументов у меня не будет.
Объёмы запоминающих устройств и битрейт каналов связи уже сейчас позволяют не слишком сильно переживать по поводу этих "лишних" данных, и продолжают расти и дешеветь. Объектные файлы при сборке требуют десятки гигабайт хранилища, при распределённой сборке всё это прокачивается по сети туда-обратно, и на таком фоне сэкономить даже 1ГБ бинарников для сборки выглядит просто незначительным)
Очередной лицензионный платеж всегда заставляет пересмотреть свои взгляды =)
Рассматриваете переход на С++ с модулями? Наколько я понимаю, модули существенно ускоряют и упрощают компиляцияю из коробки.
Нам эта возможность пока не была доступна, поэтому досконально не изучали. Определенно будем изучать в ближайшем будущем и примерять на нашу кодовую базу.
>Наколько я понимаю, модули существенно ускоряют и упрощают компиляцияю из коробки.
Вот здесь есть отличный обзорный доклад, из доклада следует, что модули существенно меняют модель компиляции и призваны решить множество проблем, даже как будто не только и не столько проблему медленной компиляции. Что из всего этого выйдет для нашего проекта покажет только практика.
Кстати занятно, что первый же комментарий под докладом про jumbo в chromium ?
Вероятно, я не очень внимательно прочел, но у меня сложилось представление, что такой драматический прирост скорости сборки случился из-за перехода на распределенную систему. Правильно ли я понимаю, что если не рассматривать распределенную сборку, то и кратного ускорения не получится?
Правильно ли я понимаю, что если не рассматривать распределенную сборку, то и кратного ускорения не получится?
Зависит от кодовой базы, но кажется что скорее Unity приводит к кратному ускорению в большинстве случаев.
Распределенная сборка усилила другие возможности после того как мы стали их использовать. Само по себе распределение задач по сети на нашей кодовой базе давало небольшой выигрыш (или даже замедление в патологических случаях) из-за особенностей PCH и других нюансов. Однако же на других проектах в компании одной распределённой сборки хватило для ускорения в 10 раз.
Для CI конвейера наиболее заметное ускорение произошло после настройки распределённого кэша. В этом случае распределённая сборка помогает при кэш промахах.
Для рабочего места наибольшего прироста добиваемся с помощью Unity. В этом случае сеть помощников помогает собирать тяжелые Unity файлы
А как поступать со сгенерированными MIDL компилятором файлами? У меня генерируется header с помощью директивы #import, как указать системе сборки, чтобы он сперва должен быть скомпилирован, а потом включён в граф файловых зависимостей. И ещё он каким-то магическим образом оказывается в папке с объектными файлами.
Как мы ускорили сборку CAD-программы на С++ в несколько раз