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