Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: Скорость сборки проекта  (Прочитано 15865 раз)
0 Пользователей и 1 Гость смотрят эту тему.
lapulya
Молодой специалист

ru
Offline Offline

« : 21-12-2009 17:12 » 

А, да. Собственно, мне случалось использовать это решение и не для шаблонов Улыбаюсь Когда требовалось резко снизить время на компиляцию-линковку.
Вад, не понимаю как можно резко снизить время на линковку и тем более на компиляцию делая инклуд cpp файла? По идее для компилятора нет никакой разницы какое расширение у файла, можно все писать в cpp, можно все писать в h файлах, нет никакой разницы кроме удобства (собственно поэтому и разделили).
« Последнее редактирование: 22-12-2009 09:52 от Вад » Записан

С уважением Lapulya
Вад
Модератор

ru
Offline Offline
Пол: Мужской

« Ответ #1 : 21-12-2009 20:46 » 

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

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

ru
Offline Offline
Сообщений: 13


« Ответ #2 : 22-12-2009 04:17 » 

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

Антон (LogRus)
Глобальный модератор

ru
Offline Offline
Пол: Мужской
Внимание! Люблю сахар в кубиках!


WWW
« Ответ #3 : 22-12-2009 04:27 » 

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

Странно всё это....
Алексей++
глобальный и пушистый
Глобальный модератор

ru
Offline Offline
Сообщений: 13


« Ответ #4 : 22-12-2009 04:42 » 

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

Антон (LogRus)
Глобальный модератор

ru
Offline Offline
Пол: Мужской
Внимание! Люблю сахар в кубиках!


WWW
« Ответ #5 : 22-12-2009 04:48 » 

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

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

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

Странно всё это....
Алексей++
глобальный и пушистый
Глобальный модератор

ru
Offline Offline
Сообщений: 13


« Ответ #6 : 22-12-2009 04:55 » 

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

Антон (LogRus)
Глобальный модератор

ru
Offline Offline
Пол: Мужской
Внимание! Люблю сахар в кубиках!


WWW
« Ответ #7 : 22-12-2009 04:58 » new

Алексей1153++, тогда смирись Улыбаюсь
Записан

Странно всё это....
Алексей++
глобальный и пушистый
Глобальный модератор

ru
Offline Offline
Сообщений: 13


« Ответ #8 : 22-12-2009 05:01 » 

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

Вад
Модератор

ru
Offline Offline
Пол: Мужской

« Ответ #9 : 22-12-2009 08:07 » 

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

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

ru
Offline Offline
Сообщений: 13


« Ответ #10 : 22-12-2009 08:24 » 

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

lapulya
Молодой специалист

ru
Offline Offline

« Ответ #11 : 22-12-2009 08:29 » 

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

Прекомпайлед отключен (вообще всегда это Г отключаю), но компиляция + сборка идет менее 5 минут (речь не о ребилд ол, а об обычной сборке после внесения правок внесенных вами, такие сборки идут не реже раза в день, т.е. изменения ограничиваются вашими изменениями за 1 день). Если сборка идет дольше 5 минут, значит вы плохо спроектировали проект или делаете инклуды хеадеров в хеадеры где это не нужно (это нужно только при наследовании, использовании stl и, возможно, констант и перечислений)
« Последнее редактирование: 22-12-2009 08:33 от lapulya » Записан

С уважением Lapulya
Алексей++
глобальный и пушистый
Глобальный модератор

ru
Offline Offline
Сообщений: 13


« Ответ #12 : 22-12-2009 08:36 » 

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

lapulya
Молодой специалист

ru
Offline Offline

« Ответ #13 : 22-12-2009 08:43 » 

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

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

С уважением Lapulya
lapulya
Молодой специалист

ru
Offline Offline

« Ответ #14 : 22-12-2009 08:44 » 

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

С уважением Lapulya
Вад
Модератор

ru
Offline Offline
Пол: Мужской

« Ответ #15 : 22-12-2009 08:45 » 

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

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

ru
Offline Offline
Сообщений: 13


« Ответ #16 : 22-12-2009 08:52 » 

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

lapulya
Молодой специалист

ru
Offline Offline

« Ответ #17 : 22-12-2009 09:03 » 

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

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

С уважением Lapulya
lapulya
Молодой специалист

ru
Offline Offline

« Ответ #18 : 22-12-2009 09:09 » 

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

Да, убеждаться что все работает с правками соседа должен тест (ну или сотрудник отдела тестирования), но не как не программист, да еще и с чужим для него кодом. Если интерфейс согласован, мой модуль работает корректно, то это не моя проблема! Это командная работа, каждый отвечает за свой кусок, есть проблемы - приходи поговорим (мы иногда всей комнатой, 5 - 6 человек, решали чью-то проблему, ну действительно ошибки были очень трудно отыскиваемыми)... Но если он считает, что у него проблем нет, т.е. все волшебно, то проблема работы его модутя это его проблемы, его ответственность.
« Последнее редактирование: 22-12-2009 09:14 от lapulya » Записан

С уважением Lapulya
Алексей++
глобальный и пушистый
Глобальный модератор

ru
Offline Offline
Сообщений: 13


« Ответ #19 : 22-12-2009 09:23 » 

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

Вад
Модератор

ru
Offline Offline
Пол: Мужской

« Ответ #20 : 22-12-2009 09:51 » 

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

Поэтому я и не имел в виду, что код не компилируется. Разумеется, код выкладывали компилируемый, а в случае косяков виновник огребал по ушам. Нужно было, чтобы код работал. Да, у проекта были проблемы. Поскольку это было не конечной разработкой под ключ, никакого такого масштабного тестирования там практически не было. Ведь основное требование к прототипу - демонстрировать, что идея работоспособна. Что он и демонстрировал. Но поэтому следить за работоспособностью кода приходилось только через девелоперские тесты (если была возможность написать автономный тест) и пуск свежих билдов. 2 билда в день делались, конечно, не всегда Улыбаюсь Но если был срочно нужен свежий билд, ждать по полчаса - это как-то, по-моему, чересчур.
« Последнее редактирование: 22-12-2009 09:55 от Вад » Записан
lapulya
Молодой специалист

ru
Offline Offline

« Ответ #21 : 22-12-2009 10:30 » 

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

С уважением Lapulya
Страниц: [1]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines