Здравствуйте, Сергей Мухин, Вы писали:
СМ>>>дада, но эта информация у нее уже в голове, это быстро происходит
NBN>>Это при условии, что компилер помнит используемые хидеры. А если нет — то нужно всё парсить.
СМ>парсится один раз, потом хранится (где ниб в suo/ncb) и меняется при изм файлов
Здравствуйте, NikeByNike, Вы писали:
СМ>>парсится один раз, потом хранится (где ниб в suo/ncb) и меняется при изм файлов
NBN>Это не вижалковский компилятор
ну это проблема среды. если нет — так нет. При полном перестроении зависимость и не нужна
Здравствуйте, NikeByNike, Вы писали:
PD>>Не знаю как в твоем компиляторе, но VS проверяет не файлы, а их дату и время. Если obj более поздний, чем cpp — значит, не надо компилировать.
NBN>Не. Она так же проверяет все связанные с cpp хидера. Иначе при изменении хидера не происходило бы перекомпиляции (у других компилеров такое бывает).
Здравствуйте, NikeByNike, Вы писали:
NBN>Пробую разные способы ускорить компиляцию.
Случайно нашел в студии 2010 ключик, который показывает таймирование, что-то вроде такого:
1> 1 ms MakeDir 11 calls 1> 2 ms WriteLinesToFile 4 calls 1> 2 ms SetEnv 4 calls 1> 15 ms CppClean 1 calls 1> 45 ms RC 1 calls 1> 305 ms Link 1 calls 1> 692 ms BSCMake 1 calls 1> 1063 ms CL 2 calls
может пригодиться
Tools\Options...\Projects and Solutions\VC++ Project Settings\Build Timing
Здравствуйте, NikeByNike, Вы писали:
D>>, да и процессор многоядерный даст огромный прирост, i7 например.
NBN>i5 стоит. Мне не кажется, что проц тут узкое место...
Это вам кажется. Проц при компиляции и есть узкое место!
См. загрузку проца во время компиляции — она практически всегда 100%. Если бы проседал дисковый ввод/вывод то проц бы не использовался так интенсивно.
Увеличение количества ядер и ключик /MP (VS компилятор) дают практически линейный прирост производительности.
А компилятор то поддерживает параллельное компилирование?
Здравствуйте, NikeByNike, Вы писали:
NBN>Пробую разные способы ускорить компиляцию. NBN>Есть некоторый проект весом порядка 5-10 Mb исходников. Кроме того он ссылается на порядка 20 Mb сторонних библиотек и SDK.
Неужели на полный билд этого проекта требуется более чем 10 минут?
Из собственного опыта: куда более достаёт работа линкера, когда даже на минорные правки система откликается молниеносной компиляцией, но долгим ворочанием объектников всяких либ, собирая монолитный EXE или "супер-главную DLL". Поэтому может быть полезно переосмыслить набор свой бинарей, хотя бы для debug-сборки.
NBN>Win7 (64), VS 2005, 4 гига (можно расширить до 8).
А смысл расширять есть? Всё равно 64-битной версии самой Студии пока нет и не предвидится, вроде.
Здравствуйте, Mr.Delphist, Вы писали:
MD>Неужели на полный билд этого проекта требуется более чем 10 минут?
10 минут — раздражают. Хочется чтобы оно происходило за минуту или быстрее
MD>Из собственного опыта: куда более достаёт работа линкера, когда даже на минорные правки система откликается молниеносной компиляцией, но долгим ворочанием объектников всяких либ, собирая монолитный EXE или "супер-главную DLL". Поэтому может быть полезно переосмыслить набор свой бинарей, хотя бы для debug-сборки.
Он и так переосмыслен.
NBN>>Win7 (64), VS 2005, 4 гига (можно расширить до 8).
MD>А смысл расширять есть? Всё равно 64-битной версии самой Студии пока нет и не предвидится, вроде.
Меня интересовал алгоритм создания диска в оперативной памяти и моунтинг его в качестве определённой папки на другом диске.
Здравствуйте, NikeByNike, Вы писали:
NBN>Здравствуйте, Mr.Delphist, Вы писали:
MD>>Неужели на полный билд этого проекта требуется более чем 10 минут? NBN>10 минут — раздражают. Хочется чтобы оно происходило за минуту или быстрее
Уточню вопрос: это именно инкрементальный билд — 10 минут?
Если да, то что за фарш из шаблонов там применяется? Хотя, тогда вряд ли что-то заметно поможет, кроме IncrediBuild и прочих "облаков".
Если нет, то зачем на дев-машине всегда делать полные билды? Для этого билд-сервер можно припрячь.
Здравствуйте, Mr.Delphist, Вы писали:
MD>>>Неужели на полный билд этого проекта требуется более чем 10 минут? NBN>>10 минут — раздражают. Хочется чтобы оно происходило за минуту или быстрее
MD>Уточню вопрос: это именно инкрементальный билд — 10 минут?
Нет, это полный билд. Который приходится устраивать сравнительно часто по техническим причинам.
MD>Если нет, то зачем на дев-машине всегда делать полные билды? Для этого билд-сервер можно припрячь.
Недостаточно крупный проект.
Здравствуйте, NikeByNike, Вы писали:
MD>>Если нет, то зачем на дев-машине всегда делать полные билды? Для этого билд-сервер можно припрячь. NBN>Недостаточно крупный проект.
Это похоже уже на оффтоп, но ИМХО тут надо менять начальство, либо компанию вместе с начальством. У нас даже для самого маленького пилота найдется вся инфраструктура: билд-сервер, репозиторий кода, баг-трекер, портал SharePoint для документов. Ибо это поставлено у админов на поток, достаточно кинуть email с заявкой, они соберут всё как конструктор.
Здравствуйте, Mr.Delphist, Вы писали:
MD>>>Если нет, то зачем на дев-машине всегда делать полные билды? Для этого билд-сервер можно припрячь. NBN>>Недостаточно крупный проект.
MD>Это похоже уже на оффтоп, но ИМХО тут надо менять начальство, либо компанию вместе с начальством. У нас даже для самого маленького пилота найдется вся инфраструктура: билд-сервер, репозиторий кода, баг-трекер, портал SharePoint для документов. Ибо это поставлено у админов на поток, достаточно кинуть email с заявкой, они соберут всё как конструктор.
Компания замечательная. Меня админы уговаривали компилировать на билдсервере.
Я считаю, что для данного проекта это неудобно и неразумно. Особенно если удастся повысить скорость компиляции ещё немного
Здравствуйте, NikeByNike, Вы писали:
NBN>Есть некоторый проект весом порядка 5-10 Mb исходников. Кроме того он ссылается на порядка 20 Mb сторонних библиотек и SDK. NBN>Win7 (64), VS 2005, 4 гига (можно расширить до 8).
Ага — переехать на VS2008 и заюзать ключик /MP.
Я после увиденного свернул все работы на 2005-ой. Хотя её компилятор меня полностью устраивал.
На 8 гигах будет реально комфортнее работать. У меня Vista x64.
---
Проект на чистом C++. Габариты приблизительно такие же — в районе 25MB исходников.
До поры до времени его мог асилить и компилятор от BCB5. Кстати — он в один поток компилировал практически с той же скоростью, что и VC9 на четырех ядрах. Правда бинарник получался в 2.5 раза тяжелее и он не работал
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, ilvi, Вы писали:
D>>Кажется VS 2005 не умеет запускать паралельно компиляцию одного проєкта. Хотя тут пишут другое
I>И правильно пишшут. На рабочей машине двухядерный процессор. MSVC 2005 без ключа /MP у меня запускает один процес cl.exe, а с этим ключом два.
Во блин. А я свято верил, что эта фича появилась только в VS2008
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Коваленко Дмитрий, Вы писали:
NBN>>Есть некоторый проект весом порядка 5-10 Mb исходников. Кроме того он ссылается на порядка 20 Mb сторонних библиотек и SDK. NBN>>Win7 (64), VS 2005, 4 гига (можно расширить до 8).
КД>Ага — переехать на VS2008 и заюзать ключик /MP.
КД>Я после увиденного свернул все работы на 2005-ой. Хотя её компилятор меня полностью устраивал.
Просмотрел сообщения этого топика.
Гы — оказывается VC8 тоже поддерживает /MP. Попробовал — действительно поддерживает и распараллеливает компиляцию.
Жаль потерянное время...
---
Век живи — век учись
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
вроде должно получиться, хотя "примаунтить как папку" я никогда не пробовал.
способ с RAM диском — хороший вариант ускорения компиляции,
но не стоит забывать и о "классике" — компиляции в несколько потоков.
начиная с VS2008 появилась соответствующая опция компилятора.
а так большие проекты обычно собираются не VS-проектами, а тулзами,
которые позволяют делать эти и другие удобные вещи (gnumake, scons, etc).
другие менее радикальные средства — это precompiled header и написание
кода с минимумом зависимостей.
