Comments 45
100 МБ исходников;
А в видео говорится про 500.
+1
Есть такая штука ccache, ускоряет сборку в разы а то и более…
Вроде есть и под Win. Не пробовали ещё и её использовать?
Имею ввиду не «вместо», а дополнительно… (т.к. у вас есть c++ код).
Вроде есть и под Win. Не пробовали ещё и её использовать?
Имею ввиду не «вместо», а дополнительно… (т.к. у вас есть c++ код).
+9
А в чем смысл? С таким же успехом можно просто clean не делать, и неизмененные файлы не будут комипилироваться.
0
ccache более интеллектуальное и мощное средство
+1
Не скажите. Ccache имеет неприятную особенность иногда ломать кэши. Под гентой бывает сборка пакеты вываливается с ошибкой об неверном формате объектника, после чистки кэша или отключения — всё ок. Не знаю, с чем именно это связано, но факт имеет место быть. Возможно коллизии хешей, возможно баг. А возможно у меня диск посыпался…
0
ccache не только это кеширует. Если, например, есть общие исходники у разных проектов, то он будет кешировать объекты и такого плана.
А если clean сделать, то он тоже ускоряет процесс, так как многие вещи не меняются.
Я думаю, что есть смысл поэкспериментировать. Это не панацея, конечно, но попробовать есть смысл.
А если clean сделать, то он тоже ускоряет процесс, так как многие вещи не меняются.
Я думаю, что есть смысл поэкспериментировать. Это не панацея, конечно, но попробовать есть смысл.
+2
Пробовали и используем. Действительно, в некоторых случаях работает более эффективно чем студийный build без clean. Для MSVS эта штука называется clcache, мы немного отредактировали ее первоначальный вариант отсюда https://github.com/frerich/clcache
0
Интересно, а нафига? У вас каждый раз меняются все 176 проектов, что их надо перекомпилировать? Из собственного опыта: около 300 проектов в работе, побиты логичненько на около 20 сольюшенов. В результате, если я поменял что-то — не нужно пересобирать все 300 — только группу проектов данного сольюшена — а это считанные секунды. Конечно, когда меняется какая-то корневая библиотека, от которой всё зависит — надо пересобрать всё. Но в проектах такого масштаба все низкоуровневые блоки уже давно написаны, меняются только высокоуровневые части.
0
А что у вас за софт который состоит из 300 проектов?
0
Софт как софт, мультемедию всякую колбасим. Деталей рассказывать не могу, но вот представьте себе, что у вас есть музыка и видео и все возможные действия с ними: играть, конвертить, редактировать, искать, загружать, захватывать, стримить, бекапить, записывать на диски, покупать, искать слова песен, узнавать песни по их кусочкам и еще 100 тыщ разных действий. При этом 300 проектов — фигня, у нас и по 500 бывает и по 1000.
0
Под проектом понимается отдельно взятая опция программы? Да даже программа с 500 опциями это уже перебор. Этакий швейцарский нож. А мы уже не раз читали что швейцарские ножи это плохо. Это десктоп или веб портал? если веб портал то почему на С++. Или у вас не С++?
0
Именно тот факт, что каждая опция программы по сути является подключаемым (или отключаемым) плагином, отдельной библиотекой и позволяет жить проекту такого масштаба. Может быть лайт-версия с десятком самых необходимых фич, может быть версия для профи, могут быть плагины, скачиваемые по требованию и т.д. И именно это позволяет ребилдить при правках не все 300 проектов, а только то, что нужно. Именно это позволяет не быть швейцарским ножом в среднем и всё-таки быть им тогда, когда это необходимо. В общем, проектик живет уже лет 15 и еще столько же проживет.
0
Ключ /Z7, который отключает генерацию отладочной информации, в результате чего компиляция производится быстрее.
Разве не наоборот?
Тоже раньше думал, что создание отладочной информации затратно, но после внедрения Symbol/Source сервера отлаживать релизные модули стало на порядок удобнее.
Разве не наоборот?
/Z7
Produces an .obj file containing full symbolic debugging information for use with the debugger.
Тоже раньше думал, что создание отладочной информации затратно, но после внедрения Symbol/Source сервера отлаживать релизные модули стало на порядок удобнее.
0
Странно, что рамдиск быстрее, чем одиночный SSD, и странно, что SSD от HDD почти не отличается.
Пробовал наш проект в различных вариациях, ~ 70 проектов в солюшене, размер исходников правда не мерял, бусты, апачевские и прочие библиотеки лежали внутри, с пребилдом, лень было отсеивать.
На SSD проект раза в 4 быстрее собирался, чем на HDD, а рамдиск медленнее чем SSD процентов на 30. Из чего сделал вывод, что чтение с SSD уже дает достаточную пропускную способность, а рамдиск только ресурсы у компилятора отнимает.
Пробовал наш проект в различных вариациях, ~ 70 проектов в солюшене, размер исходников правда не мерял, бусты, апачевские и прочие библиотеки лежали внутри, с пребилдом, лень было отсеивать.
На SSD проект раза в 4 быстрее собирался, чем на HDD, а рамдиск медленнее чем SSD процентов на 30. Из чего сделал вывод, что чтение с SSD уже дает достаточную пропускную способность, а рамдиск только ресурсы у компилятора отнимает.
0
Возможно использовался standalone ram-диск. Делать ram-диск за счет оперативной памяти самого компьютера точно не рационально.
0
Т.е. писать на диск, ждать — это рационально, а писать на рам-диск, который быстрее — не рационально?
+3
В изначальном комментарии человеку показалось странным, что запись на рам-диск быстрее, чем SSD, хотя по его экспериментам выходило вроде как наоборот.
0
Запись на RamDisk (не standalone) действительно быстрее, чем на SSD. Так что очень даже рационально за счет памяти самого компьютера.
+1
Если тупо копировать файл, то да. А вот если компилировать — то тут уже все не так радужно. Просто приведу специально выпуклый пример — при равном hardware где быстрее скомпилируется крупный проект — на 8GB оперативной памяти и обычном HD или на 1GB оперативки с 7 GB рам-диском?
0
Конечно же быстрее будет с 4-8Gb оперативки и 8GB рам-диском.
+1
Если вы будете 8GB рам диск делать за счет своей оперативки компьютера, то компилироваться может не сильно быстрее, чем при использовании 16 GB памяти без рам-диска. Проверено на крупном проекте. Именно поэтому желательно использовать харжварный рам-диск (т.е. не софтварный).
0
А сам RamDisk тестировали? Они же разные бывают и не все «одинаково полезны». Некоторые из них дают приемлемые результаты на определенных размерах кластера, и это не 4096.
0
Сам рамдиск(пробовал dataram) дает заоблачные показатели скорости копирования, 5гб в секунду влегкую.
0
Сам им пользуюсь, только кластер выставил 32кб, чтобы быстрее работало.
Но почему тогда:
Но почему тогда:
Странно, что рамдиск быстрее, чем одиночный SSD?
0
Как я уже написал, считаю, что ПСП и процессорное время отнимает у компилятора. Там же не просто чтение из памяти, он файловую систему имитирует, драйверы и все такое.
А скорость чтения уже не узкое место, далее расширять не дает прироста.
У меня медленнее. 2.5 минуты против 3х с копейками.
А скорость чтения уже не узкое место, далее расширять не дает прироста.
У меня медленнее. 2.5 минуты против 3х с копейками.
0
У меня проект не слишком большой, и я не весь его держу на RamDrive, а только временные файлы компиляции там складируются и %TEMP%. Ускорение есть, но точные значения уже не помню. А какой у вас был размер кластера? Я смотрел сравнительные характеристики — на 4кб Dataram не ахти, видимо сказывается как раз оверхед файловой системы, а 32кб и выше — уже существенно лучше.
0
Для наших проектов на C/C++ для Windows при достаточном количестве оперативки SSD сборку ускорял процентов на 15%. %Temp% на рам-диске дает больший выигрыш.
+2
Кто подскажет, откуда диаграмма времени работы процессов? Полезная штука в хозяйстве, чем отслеживать визуально в ProcessMonitor.
0
Только недавно интересовался подобной информацией относительно больших C++ проектов, но к сожалению информации не так много.
Было бы интересно узнать о той оптимизации кода, которую провели на начальном этапе.
На данный момент работаем над проектом, архитектура которого не самая удачная и требует реорганизации, но из-за размеров (более 300 проектов в солюшене) провести мгновенную оптимизацию невозможно. На текущий момент, пересборка проекта, с IncrediBuild занимает порядка 1.5 часа, иногда больше.
Может быть есть у кого подобный опыт, чтобы подсказать в какую сторону копать, и как постепенно привести проект к более лучшей организации, и как результат уменьшить время сборки?
P.S проект написан на C++, платформа Windows.
Было бы интересно узнать о той оптимизации кода, которую провели на начальном этапе.
На данный момент работаем над проектом, архитектура которого не самая удачная и требует реорганизации, но из-за размеров (более 300 проектов в солюшене) провести мгновенную оптимизацию невозможно. На текущий момент, пересборка проекта, с IncrediBuild занимает порядка 1.5 часа, иногда больше.
Может быть есть у кого подобный опыт, чтобы подсказать в какую сторону копать, и как постепенно привести проект к более лучшей организации, и как результат уменьшить время сборки?
P.S проект написан на C++, платформа Windows.
0
Дайте угадаю. В проекте используются шаблоны. Используются в неимоверном количестве?
0
Все относительно.
Конечно есть и шаблоны — много ли их? — встречаются, да и сам иногда пишу небольшие.
Вопрос в другом — в какую сторону смотреть, чтобы ситуацию улучшить, вот раньше упоминали модульность, которой как таковой в проекте сейчас немного, может есть у кого опыт постепенного обновления архитектуры проекта?
Конечно есть и шаблоны — много ли их? — встречаются, да и сам иногда пишу небольшие.
Вопрос в другом — в какую сторону смотреть, чтобы ситуацию улучшить, вот раньше упоминали модульность, которой как таковой в проекте сейчас немного, может есть у кого опыт постепенного обновления архитектуры проекта?
0
Мы постараемся сделать подобное описание в одном из следующих постов.
+1
поделитесь опытом: каким инструментом вы пользовались для получения диаграммы процесса сборки?
+1
да очень похоже — спасибо
0
дает использование 32 процессоров с технологией Hyper Threading
Где вы взяли 8-ми процессорный сервер?!
Где вы взяли машину на 32 процессора?
Или это несколько серверов? (Тогда я не увидел, где написано, что вы перешли на распределенные технологии)
Или это 32 ядра на 4-х процессорной машине?
0
Sign up to leave a comment.
Оптимизация сборки крупного проекта