Visual studio компиляция без зависимостей
Введение
Основная масса программистов на С++ принимает долгую компиляцию как должное. Совсем по другому эту ситуацию воспринимают программисты, перешедшие на С++ с других языков, в которых используются быстрые компиляторы (Basic, Delphi). Подход к программированию во многом зависит от скорости компиляции и линковки: если компилятор собирает проект за несколько минут – вы не будете пользоваться им для тестирования небольших изменений, используя же быстрый компилятор вы имеете возможность без потери времени оттестировать практически каждое изменение в коде. Здесь не будет рассматриваться вопрос «зачем нужна быстрая компиляция», здесь я расскажу как сделать С++ компилятор быстрым.
Статья состоит из нескольких разделов, посвященных отдельным инструментам и настройкам, позволяющим ускорить работу компилятора.
Выбор компилятора.
Ничто так не ускоряет работу компилятора как его правильный выбор. Многие программисты выбирают OpenSource-решения в духе MinGW, надеясь сэкономить или из принципиальных побуждений. MinGW весьма медленный компилятор. Intel - немного быстрее. Лучшие результаты по скорости компиляции показывает Microsoft Visual C++. Если хотите еще более быстрой компиляции - отключите все оптимизации.
Precompiled headers
Precompiled headers – это набор заголовочных файлов, которые собираются один раз и при повторной сборке проекта очень быстро линкуются. В список precompiled headers нужно добавлять все те заголовочные файлы, которые содержат стабильный неизменный код или меняются очень редко. Для MSVC++ по умолчанию список этих файлов содержится в stdafx.h, который должен быть подключен во все cpp файлы самым первым.
IncrediBuild
IncrediBuild – инструмент, который интегрируясь в MS Visual Studio, позволяет распараллеливать компиляцию по всем подключенным к IB компьютерам в сети. Безусловно, замечательный инструмент, но с серьезным недостатком: скорость линковки ниже, чем при обычной сборке, да и необходимость рассылать всем исходные коды и получать результат, сказывает отрицательно. Выигрыш в скорости вы получите только если проводите rebuild проекта. При штатной разработке IncrediBuild обычно работает немного медленней обычной компиляции.
Ram Disk
Ram Disk – это виртуальный винчестер, с которым система работает как с обычным винчестером, но физически расположенный в оперативной памяти. Объем такого диска весьма ограничен, но 100 мегабайт достаточно, чтобы хранить все скомпилированное приложение. Использование Ram Disk – один из самых эффективных способов ускорить компиляцию и сборку С++ проекта, в этом случае основная нагрузка ложится на процессор и нет торможения из-за медленной скорости чтения/записи винчестера.
ВАЖНО! Ram Disk – работает с оперативной памятью, а значит любой сбой в работе вашего ПК потенциально может привести к полной потери информации. В связи с чем не стоит переносить исходные коды на Ram Disk, размещайте на нем только сборку.
Qt
Qt - замечательный инструмент для разработки приложений, но входящий в него qmake работает очень медленно. Поработав с этим инструментом, мы пришли к следующему принципу его использования: при разработке кода ядра и кода игры не используется Qt, следовательно не требуется запуск qmake. При этом весь инструментарий использует Qt для интерфейсов и для реализации внутренней логики, не связанной с кодом движка.
Есть в этом некоторое кощунство – использовать Qt как редактор интерфейса, но полноценное использование функционала Qt в разработке игр несет больше проблем, чем реальной пользы.
Модульность
По возможности выделяйте для каждого класса отдельный модуль. Чем меньше кода нужно переработать компилятору – тем быстрее он это сделает. Готовые модули добавляйте в список precompiled headers.
Итоги
Самый быстрый компилятор – Microsoft Visual C++ с полностью отключенными оптимизациями кода.
Для того, чтобы убрать зависимость от скорости работы винчестера, лучше использовать Ram Disk, не забывая при этом периодически сбрасывать исходные коды на винчестер.
IncrediBuild хорошо помогает при rebuild проекта, но в обычной работе только мешает.
Qt – это хорошо, но слишком медленно и для больших игр не годится.
Код разбивайте на логические блоки и по возможности храните эти блоки в отдельных модулях.
Применив эти нехитрые приемы, вы добьетесь удивительного результата: одна секунда компиляции на код, содержащий несколько мегабайт текста.
И еще интересует такой вопрос, неужели на с++ нигде нет никакого визуального редактора форм ? Всё на winapi писать нужно ? Ну qt, но ведь там насколько я понял нужно тянуть библиотек 10 или больше по 5-6 мегабайт ?
Благодарю заранее за помощь и советы.
Dll без внешних зависимостей?
Добрый день, Волею судьбы приходится писать программы для C++Builder XE8. К несчастью, библиотеки.
Компиляция зависимостей
среда Netbeans 7.3 проект maven - spring - hibernate Главным проектом назначен java web.
Сборка qt без зависимостей
Собирал по этому мануалу, но в каталоге bin не появились необходимые dll. Сборка завершилась.
Может кто подсказать как так скомпилировать чтобы запустилось на любой ос и человеку не нужно было лазить искать доп. дистрибутивы.
1. Компилить в Release.
2. Использовать опцию "Runtime Library = Multi-Threaded (/MT)" в
настройках C++ проекта.
3. На Visual Studio 2012 и выше использовать XP toolset для того,
чтобы программа могла работать на Windows XP и Server 2003.
4. Не использовать функции и интерфейсы системы, которые
появились только в последних версиях Windows.
И будет работать везде.
А про зависимости кто-нибудь, что-нибудь знает ? Что да как, каким образом они компилируют что программа везде запускается. Где-то читал про статическую компиляцию какой-то ключ /MT вместо /MD в студии такого не нашел в настройках компилятора проект Win32 Application, вот программа 300кб весит одним файлом, имеет и диалоговые окна и кнопки т.д. никаких зависимостей, везде запускается. Я просто разрываюсь уже столько этих компиляторов установил. Вроде нужен и такой чтобы зависимостей никаких не было, но с другой стороны нужен хороший визуальный редактор интерфейса, на winapi писать это очень долго и нудно придется изучать функции winapi. Может кто дать совет, на данный момент приложение на WPF, в основном используются картинки (background image) для контролов и в зависимости от событий они меняются. Вот приблизительно такой функционал визуального редактора нужен, а там уже в зависимости от событий менять эти картинки на другие. Единственный аналог пока Qt, но там эти dll скомпилировал приложение начало требовать QtCore5.dll, потом Widgets.dll потом еще что-то. Пока в поисках
Процедуры, описанные в этом разделе, используются для построения, перестроения или очистки всех или некоторые проектов или элементов проекта в решении. Пошаговые инструкции см. в разделе Пошаговое руководство. Построение приложения.
Этот раздел относится к Visual Studio в Windows. Информацию о Visual Studio для Mac см. в статье Создание и очистка проектов и решений в Visual Studio для Mac.
Пользовательский интерфейс в вашем выпуске Visual Studio может отличаться от приведенного в этом разделе в зависимости от ваших текущих параметров. Чтобы изменить параметры, например на Общие или Visual C++, выберите Сервис > Импорт и экспорт параметров, а затем щелкните Сбросить все параметры.
Сборка, перестроение или очистка всего решения
В обозревателе решений откройте решение или выберите нужное решение.
В строке меню выберите Сборка, а затем одну из следующих команд.
Выберите Собрать или Собрать решение либо нажмите клавиши CTRL+SHIFT+B, чтобы скомпилировать только те файлы и компоненты проекта, которые были изменены с момента последней сборки.
Если решение содержит несколько проектов, команда Собрать меняется на Собрать решение.
Выберите Перестроить решение, чтобы очистить решение, а затем собрать все файлы и компоненты проекта.
Выберите Очистить решение, чтобы удалить промежуточные и выходные файлы. После этого, когда останутся только файлы проекта и компонентов, можно собрать новые экземпляры промежуточных и выходных файлов.
Сборка или перестроение одного проекта
В обозревателе решений выберите или откройте решение.
В строке меню щелкните Собрать, а затем выберите либо Собрать Имя_проекта, либо Перестроить Имя_проекта.
Выберите Собрать Имя_проекта, чтобы выполнить сборку только тех компонентов проекта, которые были изменены с момента последней сборки.
Выберите Перестроить Имя_проекта, чтобы очистить проект, а затем выполнить сборку файлов проекта и всех его компонентов.
Сборка только запускаемого проекта и его зависимостей
В строке меню выберите Сервис > Параметры.
В диалоговом окне Параметры разверните узел Проекты и решения и выберите страницу Сборка и запуск.
Откроется диалоговое окно Сборка и запуск > Проекты и решения > Параметры.
Установите флажок При выполнении построить только запускаемые проекты и зависимости.
Если этот флажок установлен, при выполнении любого из указанных далее действий выполняется сборка только текущего запускаемого проекта и его зависимостей.
В строке меню выберите Отладка > Начать (или F5).
В строке меню последовательно выберите Сборка > Собрать решение (или CTRL+SHIFT+B).
Если этот флажок снят, все проекты, их зависимости и файлы решения создаются при выполнении любой предыдущей команды.
Сборка только выбранного проекта Visual C++
Выберите проект C++, а затем в строке меню выберите Сборка > Только проект и одну из следующих команд:
Только собрать Имя_проекта
Только перестроить Имя_проекта
Только очистить Имя_проекта
Только связать Имя_проекта
Эти команды применяются только к выбранному проекту C++ без сборки, перестроения, очистки или связывания зависимостей проектов и файлов решения. В зависимости от используемой версии Visual Studio подменю Только проект может содержать дополнительные команды.
Компиляция нескольких элементов проекта C++
В обозревателе решений выберите несколько файлов со скомпилированными действиями, откройте контекстное меню для одного из этих файлов, а затем выберите Компилировать или нажмите клавиши CTRL+F7.
Если файлы имеют зависимости, они будут скомпилированы в порядке зависимостей. Операция компиляции завершится ошибкой, если файлам требуется предкомпилированный заголовок, который недоступен при компиляции. Операция компиляции использует текущую активную конфигурацию решения.
Остановка сборки
Выполните одно из следующих действий.
В строке меню выберите Сборка > Отменить.
Сразу скажу, что в финале мне удалось добиться сокращения времени компиляции решения с 4:24 минут до менее чем одной минуты. Детали под катом.
На старт!
В начале я собирался собрать отдельную тестовую машину с «чистой» ОС и одной лишь установленной программой — Visual Studio. Но потом решил, что тестировать сферических коней в вакууме будет не совсем верно. На компьютере программиста так или иначе будут установлены какой-нибудь браузер, антивирус, файловый менеджер, архиватор, текстовый редактор и т.д., а значит Студии придется работать со всем этим по близости. Значит, в таком режиме и будем её тестировать, на обычном компьютере разработчика (переустановив, правда, ради чистоты эксперимента, операционную систему и поставив свежие версии используемых в работе программ).
Набор экспериментов составлен по советом с сайтов Stackoverfow, RSDN, форумов MSDN, выдачи Google ну и просто из головы.
Объектом тестирования станет время полной компиляции решения. Перед каждым экспериментом вся папка проекта будет удаляться, код будет заново заливаться из репозитория, а Visual Studio перезагружаться. Каждый эксперимент будет повторяться трижды, результатом будет среднее время. После каждого эксперимента сделанные изменения откатываются.
Если кому-нибудь интересна аппаратная конфигурация моего компьютера, так вот она:
+ жесткий диск WD 500 Гб, 7200 RPM, 16 Мб кэш
+ Win 7 Профессиональная 32 бита со всеми возможными обновлениями
+ Visual Studio 2010 Professional с первым сервис-паком
В Windows включен режим максимальной производительности, отключен Aero и всякие анимации.
Исходное время компиляции моего решения: 4 минуты 24 секунды
Поехали!
Временные файлы — на RamDrive
Есть мнение, что самые медленные операции во время компиляции решения связаны с доступом к диску. Уменьшить это время можно путем использования RamDrive для временных файлов.
Результат: 4 минуты 13 секунд или -4.17% ко времени компиляции.
Вывод: прирост производительности имеется, хоть и небольшой. Если количество ОЗУ позволяет, этот совет можно применять в деле.
Весь проект — на RamDrive
Коль уж нам удалось немного ускорить компиляцию за счет выноса на RamDrive временных файлов, возможно получиться добиться еще лучших результатов, переместив туда всё решение (всё-таки более 4000 файлов).
Результат: 3 минуты 47 секунд или -14.02% ко времени компиляции.
Вывод: По началу этот эксперимент показался мне немного стрёмным — хранить исходники в оперативной памяти не лучший вариант (а вдруг пропадет питание?). Но, учитывая факт наличия бесперебойников, равно как и таких версий RamDrive, как от QSoft (с автоматическим дублированием измененных файлов с RamDrive на жесткий диск) убедили меня, что вариан возможен. Нужно только достаточно ОЗУ (и, по-хорошему, 64-битная ОС).
Весь проект — на флешку
Включение функции ReadyBoost в Windows
Microsoft расхваливает эту функцию именно за повышение производительности при работе с большим количеством относительно небольших блоков данных (наш вариант). Попробуем.
Результат: 4 минуты 17 секунд или -2.65% ко времени компиляции.
Вывод: вполне нормальный способ ускорения работы. Кроме необходимости 1 раз вставить флешку и настроить ReadyBoost других недостатков не имеет, а некоторый прирост производительности даёт.
Изменение количества одновременно компилирующихся проектов
Visual Studio при установке прописывает это число равным общему количеству ядер процессоров в Вашем ПК. Тем не менее, мы можем попробовать его изменить (делается это в настройках VS для С++ проектов) и оценить изменение производительности. Так как в моём компьютере 4-ядерный процессор, изначально это число было равным четырём.
Результат:
6 проектов компилируются одновременно — 4 минуты 34 секунды или +3.79% ко времени компиляции
2 проекта компилируется одновременно — 4 минуты 21 секунда или -1.14% ко времени компиляции
Вывод: я с самого начала ожидал, что увеличение числа одновременно компилирующихся проектов не даст никакого прироста производительности (так и вышло). Но вот почему уменьшение его до двух дало небольшой прирост для меня не очень понятно. Возможно, это просто статистическая погрешность, а может быть при компиляции 4-ех проектов Студия из-за их зависимостей теряет время на каком-то ожидании, что происходит реже при компиляции всего двух проектов. Если у кого-нибудь еще есть мысли по теме — прошу в комментарии.
Отключение вывода текста билда в окно Оutput
Меньше вывода текста при компиляции — быстрее результат.
Результат: 4 минуты 22 секунды или -0.76% ко времени компиляции
Вывод: прирост столь смехотворен, что не стоит даже комментариев. Он может быть как реальным, так и случайным.
Очистка корзины
Я вычитал этот совет на Stackoverflow. Аргументация была в том, что по ходу компиляции создаётся и удаляется масса мелких файлов, а процедура удаления в Windows работает медленнее при забитой корзине. Поскольку все предыдущие эксперименты я и так проводил при пустой корзине, мне пришлось проделать обратный эксперимент — положить в корзину 5000 файлов общим объёмом в 2 Гб.
Результат: 4 минуты 23 секунды или +0.38% ко времени компиляции.
Вывод: время компиляции осталось без изменений. Теория провалилась.
Ключ компилятора /MP
Ключ /MP — это тоже параллельная компиляция, но уже не проектов в решении, а файлов внутри каждого проекта.
Результат: 2 минуты 38 секунд или -40.15% ко времени компиляции
Вывод: это одно из самых существенных достижений среди всех поставленных экспериментов. Конечно, прирост столь высок в основном из-за 4-ядерности моего процессора, но вскоре такие (и еще более-ядерные процессоры) станут нормой в любом компьютере, так что включать опцию имеет смысл. При её включении компилятор честно предупреждает, что она не совместимо с ключом /Gm (Enable Minimal Rebuild), что вначале пугает — возникает мысль, что теперь при любом изменении любого файла будет происходить полная перекомпиляция решения. Так вот — нифига подобного! После изменения одного файла с кодом, как и ранее, будет перекомпилироваться только этот файл, а не всё решение. Всё, что делает ключ — это определяет выбор алгоритма определения взаимосвязей файлов кода и файлов заголовков в проекте (детальнее). Оба алгоритма неплохи и существенный прирост производительности от включения /MP во много раз превосходит недостатки от отключения /Gm.
Удаление папки решения из индекса поиска Windows
Есть мнение, что изменение файлов в папках, которые индексируются механизмом поиска ОС Windows, приводит к увеличению времени компиляции.
Результат: 4 минуты 24 секунды или никакого изменения во времени компиляции
Вывод: то ли индексирование в Windows сделано так хорошо, что вообще не замедляет работу других программ с диском, то ли это влияние минимально, то ли мне просто повезло и компиляция не совпала по времени с индексацией.
Unity Builds
Об этом механизме я рассказывал в прошлой статье.
Результат: 3 минуты 24 секунды или -22.73% ко времени компиляции.
Вывод: сокращение времени компиляции существенно. О всех достоинства и недостатках этой методики я уже писал, использовать его или нет Вы можете решить сами.
Завершение лишних программ
Работающие параллельно со Студией программы кушают память и ресурсы процессора. Их закрытие может положительно сказаться на скорости работы Студии. Итак, я закрываю Skype, QIP, Dropbox, GTalk, DownloadMaster, Mysql server.
Результат: 4 минуты 15 секунд или -3.41% ко времени компиляции
Вывод: во время компиляции придется обойтись без других программ. Никаких анекдотов и порнухи «пока оно там компилится». Вряд ли полный отказ от всех программ возможен для разработчика, но можно создать бат-файлы, включающие\выключащие все лишнее и иногда ими пользоваться.
Отключение антивируса
Если у Вас в системе установлен антивирус, то эта сволочь полезная программа постоянно проверяет все файловые операции. Таким образом, каждый участвующей в компиляции файл будет удостоен внимательного взгляда бдительного стража, что может замедлить время компиляции. Я, честно говоря, не был уверен, как настроить мой антивирус так, чтобы быть уверенным в полном игнорировании им моего проекта и попросту его удалил. Ваш антивирус, возможно, конфигурируется нужным образом.
Результат: 3 минуты 32 секунды или -19.07% ко времени компиляции
Вывод: удивительный результат. Я почему-то был уверен, что все эти *.cpp. *.h, *.obj файлы полностью антивирусом игнорируются и внимания удостоятся только скомпилированные исполняемые программы, что не очень сильно замедлит работу. Однако, факт налицо — почти минута времени экономии.
Дефрагментация жесткого диска
Файловые операции выполняются быстрее на дефрагментированом диске, а компиляция — это огромное количество файловых операций. Я специально оставил этот эксперимент напоследок, поскольку отменить дефрагментацию диска невозможно, а я хотел сделать эксперименты максимально независимыми.
Результат: 4 минуты 8 секунд или -6.06% ко времени компиляции
Вывод: практика согласуется с теорией. Поставьте себе дефрагментацию в планировщик и почаще.
Способы, которые, вероятно, помогли бы, но попробовать не вышло
Переход на 64-битную версию Windows
Есть предположение, что это дало бы некоторый прирост производительности, но портирование нашего проекта под x64, в силу его специфики, имеет не очень высокий приоритет и пока не реализовано. Соответственно, пока что нечего и тестировать.
Обновление процессора, памяти, замена HDD на SSD или RAID
Нужно сказать, что моя тестовая машинка не так уж плоха и до планового апгрейда еще далеко. Работаем с тем, что есть. По отзывам в интернете наибольшее влияние на время компиляции оказывает установка SSD.
Вынесение редко меняющихся проектов в отдельное решение
Это и так уже было сделано. Если в Вашем проекте подобное еще не реализовано — обязательно займитесь.
Xoreax's IncrediBuild или аналог
Распределение компиляции между компьютерами — это уже достаточно кардинальный шаг. Он требует покупки специального ПО, серьёзной настройки и некоторого «выворачивания наизнанку» процесса сборки. Но в очень больших проектах это может стать единственным возможным вариантом. На сайте Xoreax's IncrediBuild есть данные по приросту производительности, рассказы клиентов и куча другого спама разной полезной информации по теме.
Это всё, что я хотел рассказать о способах ускорения компиляции решений в Visual Studio, а в следующей статье я приведу несколько советов по ускорению работы самой IDE.
А если размер получаемого статического бинарника очень важен - смотри в сторону uclibc, klibc и других подобных "лёгких" реализаций libc.
Причем тут С++ не понятно. Ваш пример явно на C и требует С-шную библиотеку. А так нужно создать программу, содержающию функцию _start(), тогда ей не нужен будет libc. А бинарник создавать как то так:
gcc -Wall -o linux.o -c linux.c
ld -s -o linux linux.o
> смотри в сторону uclibc, klibc и других подобных "лёгких" реализаций libc.
Они обычно не поддерживают Си++
>> смотри в сторону uclibc, klibc и других подобных "лёгких" реализаций libc.
>Они обычно не поддерживают Си++
Под MSVC++ этого можно было добиться через ATL_MIN_CRT. Как сейчас-не знаю.
>>> смотри в сторону uclibc, klibc и других подобных "лёгких" реализаций libc.
>> Они обычно не поддерживают Си++
Извини мое любопытство, но каким образом MSVC++ относится к сборке "минимальной программы для UNIX"?
извините для меня нет разницы C++ или C, к сожалению не разбираюсь в тонкостях. :) Хотелось бы как в Visual C++ указываеш точку входа, и нет никакой зависимости crt и всякой другой ненужности пользуешся функциями спокойно из разных dll стандартных но тут не проходит указывать точку входа, все равно цепляется за libc тут подсказали компилировать с параметрами -nodefaultlibs -nostartfiles вроде как сработало
>>> Они обычно не поддерживают Си++
>Извини мое любопытство, но каким образом MSVC++ относится к сборке "минимальной программы для UNIX"?
Насколько я помню там одна из реализаций C++ stdlib была завязана на libc только в ::operator new() и ::operator delete(). Возможно если автор задастся такой целью то сможет это дело перенести на гыцацу.
Вроде как если особым флагом линкера каждую функцию в свою секцию(или как это называется) поместить и потом задать особый флаг то в бинарь попадут тока те секции что реально используются используется. Поищи в гугле на эту тему.
Ну и в линухах nss линкуется всегда динамически, так что с этим могут быть проблемы. В гугле написано что с этим можно придумать.
Читайте также: