Комментарии 39
Очистка корзины
04:24 / 04:23 +0.38%
На секунду быстрее (в порядке статистической погрешности) но при этом +0.38%?
Может или на секунду дольше или -0.38%?
Смотрите: я сказал, что провожу обратный эксперимент — засоряю корзину. С засоренной корзиной скомпилировалось на 1 секунду быстрее, значит с пустой на 1 секунду дольше. А значит метод «освободить корзину» даёт увеличение времени на 1 секунду или +0.38%. Плохо вышло, что этот эксперимент единственный «инверсный» и выбивается из ряда, но 1 секунда — это не то изменение времени, ради которого стоило переделывать 12 остальных тестов.
Хорошая статья, спасибо.
Пользовался IncrediBuild. Штука замечательная, очень ускоряет компиляцию. Но у неё есть такая особенность — если компилировать вперемешку то им, то стандартным компилятором студии, получается непредсказуемое поведение.
Пользовался IncrediBuild. Штука замечательная, очень ускоряет компиляцию. Но у неё есть такая особенность — если компилировать вперемешку то им, то стандартным компилятором студии, получается непредсказуемое поведение.
Хм. Я думал перенос всего проекта на RamDrive даст больший прирост.
сегодня проверяли на работе — нет, не особо. ramdisk ускоряят при большом числа операций ввода/вывода (особенно создание/удаление файла, что требует еще и по MFT бегать), а тут их нет.
зависит от доли cpp проектов (компиляция cpu bound).
у меня с#, ~60 проектов, 3 веб-сайта. на рамдиск замапплены папки BIN и OBJ из каждого проекта, ASP.NET Temporary Files (обе x64/x32), TEMP тоже на рамдиске. по измерениям procmon по время ребилда между этими папками у меня перемещается 2.6 GB данных.
конкретные замеры по времени я уже не вспомню, прирост получится в 3-4 раза, по perfmon при компиляции на hdd пики чтения/записи были ~8 MB/sec, при компиляции на ramdisk видны пики в ~90/sec.
Еще из наблюдений, компиляция website projects генерит очень много мелких файлов в TEMP/ASP.NET Temp, перенос их на ramdisk ускорил старт сайта после изменений в BIN/web.config.
самое главное — во время компиляции можно спокойно работать с другими программами (раньше тупило любое обращение к hdd, поискать в аутлуке было нереально)
у меня с#, ~60 проектов, 3 веб-сайта. на рамдиск замапплены папки BIN и OBJ из каждого проекта, ASP.NET Temporary Files (обе x64/x32), TEMP тоже на рамдиске. по измерениям procmon по время ребилда между этими папками у меня перемещается 2.6 GB данных.
конкретные замеры по времени я уже не вспомню, прирост получится в 3-4 раза, по perfmon при компиляции на hdd пики чтения/записи были ~8 MB/sec, при компиляции на ramdisk видны пики в ~90/sec.
Еще из наблюдений, компиляция website projects генерит очень много мелких файлов в TEMP/ASP.NET Temp, перенос их на ramdisk ускорил старт сайта после изменений в BIN/web.config.
самое главное — во время компиляции можно спокойно работать с другими программами (раньше тупило любое обращение к hdd, поискать в аутлуке было нереально)
Установка SSD и переброс на него винды, студии и проекта -1000%?
Не думаю, что можно обойти эффект от переноса проекта на RamDrive :)
У меня SSD — работает шустрее, чем с HDD ранее, но магического ускорения в разы не наблюдаю.
У меня SSD — работает шустрее, чем с HDD ранее, но магического ускорения в разы не наблюдаю.
Это был вопрос, а не утверждение. Просто слышал отзывы от людей у которых стоит SSD, что всё летает и работает в разы быстрее.
Дейстительно очень интересны результаты реальных тестов билдов на HDD/HDD в рейде и SSD.
Очень много слышу о магическом ускорении билда в разы.
Может кто сможет провести анализ у кого есть SSD для тестов?
Очень много слышу о магическом ускорении билда в разы.
Может кто сможет провести анализ у кого есть SSD для тестов?
Могу сделать сравнение HDD-RAID Vs. SSD-RAID? Возможность есть, какой проект будем использовать? Нужно что-то всем известное, чтоб показатель был как относительный, так и в попугаях по палате )
HDD-RAID 4xWD1002FAEX @ RAID10 (могу эксперимента ради сделать RAID0, но не хотелось бы)
SSD-RAID RevoDrive X2 ;)
HDD-RAID 4xWD1002FAEX @ RAID10 (могу эксперимента ради сделать RAID0, но не хотелось бы)
SSD-RAID RevoDrive X2 ;)
Может оффтоп, но не сложно было бы попробовать ASP.NET MVC вот от сюда, к примеру. Солюшен MVC/MvcDev.sln. Но там всего 411 файлов .cs, зато есть несколько тестов (а как же билд без прогона тестов?)
Но, возможно, слишком быстро будет собиратся даже с полностью чистого билда.
Но, возможно, слишком быстро будет собиратся даже с полностью чистого билда.
Какой SSD?
напишу свои результаты, делал 2,5 месяца назад, результаты немного странноваты
SSD Kingston SNV425/S2, HDD Seagate ST1000528AS
архив с исходниками KASPERSKY.AV.2008.SRCS.ELCRABE.rar (можно нагуглить)
Windows 7 X64, студия 2008, Phenom II x6, 8гб памяти
сборка этого всего для проекта, находящегося на ssd — 4.03 минуты, на hdd — 3.26
распаковка этого архива с исходниками hdd->hdd — 5.54, ssd->ssd — 1.49
SSD Kingston SNV425/S2, HDD Seagate ST1000528AS
архив с исходниками KASPERSKY.AV.2008.SRCS.ELCRABE.rar (можно нагуглить)
Windows 7 X64, студия 2008, Phenom II x6, 8гб памяти
сборка этого всего для проекта, находящегося на ssd — 4.03 минуты, на hdd — 3.26
распаковка этого архива с исходниками hdd->hdd — 5.54, ssd->ssd — 1.49
так погодите. в итоге какая конфигурация вышла? какие способы вы заюзали?
где финальный график с 4:24 до «меньше чем за минуту»? Ж)
где финальный график с 4:24 до «меньше чем за минуту»? Ж)
И все-таки удивляет результат «Весь проект — на RamDrive». Казалось бы должно быть намного лучше. Не смотрели ProcessExplorer'ом какие I/O операции происходят и какое их количество? Возможно кроме проекта еще что-то на RamDrive?
Тут имхо x64-ось + 4гига ramdrive должны намного сильнее ускорить чем на 14%.
Тут имхо x64-ось + 4гига ramdrive должны намного сильнее ускорить чем на 14%.
Ну, мне кажется дело в том, что мне пришлось создать RamDrive в 2 Гб, чтобы поместился весь проект и результаты билда. А операционка у меня 32-битная, так что из 3 с копейками Гб забрали 2, да запустили прожорливую Студию, да сама Винда кушает нормально — и начался жесткий своппинг. Т.е преимущества от RamDrive сошли на нет.
Гм… тогда не понимаю что Вы помещали на RamDrime… Имхо по минимуму надо было туда поместить сам проэкт + obj с аутпутом — т.е. чтоб во время билда максимум операции чтения шли (либ там всяких)
Если только сорсы тогда действительно особого буста не должно быть и тогда ясно откуда 14%.
На билд серверах при текущих ценах на память совсем не сложно ставить 8гиг (это для обычных, серверные можно и больше), из которых 2гига на рам совсем не жалко отдать.
Если только сорсы тогда действительно особого буста не должно быть и тогда ясно откуда 14%.
На билд серверах при текущих ценах на память совсем не сложно ставить 8гиг (это для обычных, серверные можно и больше), из которых 2гига на рам совсем не жалко отдать.
На самом деле вполне ожидаемый результат, ну разве только на пару процентов больше можно было ожидать. Современные компиляторы намного больше времени тратят на парсинг, компиляцию в промежуточный код и оптимизацию, чем на операции ввода-вывода. Я помню еще на сайте clang/llvm были графики сколько clang и gcc на что времени тратят. Там чтение/запись занимали только четверть времени.
.
«Сразу скажу, что в финале мне удалось добиться сокращения времени компиляции решения с 4:24 минут до менее чем одной минуты. Детали под катом.»
Прирост впечатляет, но 4:24 на компиляцию меня не шокирует. Тем более для С++, который компилируется медленно (в силу структуры грамматики самого языка). У меня проект, весь (считая время на компиляцию, генерацию Java-кода из XSD-определений бизнс-моделей, построения начальной схемы базы на локальном оракле, деплой всего этого под JBoss со всеми ресурсами занимается где то минут 35. Около 11 000 Java классов, около 3-4 миллионов строк кода (всего) + несколько десятков тысяч остальных файлов.
Тоже оптимизировали в свое время, сократили время с часа с лишкним до 35 минут… Но общее направление оптимизации немного другое. Общее — замечание что тормозит диск (и Дефрагментация жесткого диска полезна) и антивирус (!).
Прирост впечатляет, но 4:24 на компиляцию меня не шокирует. Тем более для С++, который компилируется медленно (в силу структуры грамматики самого языка). У меня проект, весь (считая время на компиляцию, генерацию Java-кода из XSD-определений бизнс-моделей, построения начальной схемы базы на локальном оракле, деплой всего этого под JBoss со всеми ресурсами занимается где то минут 35. Около 11 000 Java классов, около 3-4 миллионов строк кода (всего) + несколько десятков тысяч остальных файлов.
Тоже оптимизировали в свое время, сократили время с часа с лишкним до 35 минут… Но общее направление оптимизации немного другое. Общее — замечание что тормозит диск (и Дефрагментация жесткого диска полезна) и антивирус (!).
По идее время полной компиляции проекта не особо должно беспокоить программиста так как есть incremental linking. Скомпилировали однажды проект — а теперь изменения в файлах будут приводить только к генерации нескольких obj и линковке с уже готовыми обьектами с предыдущей сборки. Но это зависит от того что меняется.
Общее время компиляции более критично для ночных сборок. В процессе разработки нечасто приходится перекомпилировать все с нуля.
Для разработки интереснее время компиляции проекта, когда изменился только один файл. И это время должно быть порядка 10 секунд (лучше меньше, но 10 секунд это вполне приемлимо).
Немного офф-топика:
В этом плане (быстрая перекомпиляция изменившихся файлов) создают проблемы инструменты сборки основанные на тяжелых интерпретируемых языках типа BuildR, Gradle, или сами тяжелые языки типа Scala — у них, как правило, есть фиксированное время загрузки, доходящее зачастую до тех самых 10 секунд). Решается, как правило, поднятием фонового процесса, который занимается компиляцией, и кеширует все эти файлы.
Для разработки интереснее время компиляции проекта, когда изменился только один файл. И это время должно быть порядка 10 секунд (лучше меньше, но 10 секунд это вполне приемлимо).
Немного офф-топика:
В этом плане (быстрая перекомпиляция изменившихся файлов) создают проблемы инструменты сборки основанные на тяжелых интерпретируемых языках типа BuildR, Gradle, или сами тяжелые языки типа Scala — у них, как правило, есть фиксированное время загрузки, доходящее зачастую до тех самых 10 секунд). Решается, как правило, поднятием фонового процесса, который занимается компиляцией, и кеширует все эти файлы.
Именно так и есть. Для разработчика куда более важно время инкрементного билда.
Есть тулзы которые делают упор на incremental build time для больших проектов. Tup (http://gittup.org/tup/make_vs_tup.html) один из них. Правда у него порт на windows недопилен еще (hint-hint ищется разработчик чтобы помочь окончательно портировать это дело на windows).
Есть тулзы которые делают упор на incremental build time для больших проектов. Tup (http://gittup.org/tup/make_vs_tup.html) один из них. Правда у него порт на windows недопилен еще (hint-hint ищется разработчик чтобы помочь окончательно портировать это дело на windows).
В разработке на Java под App Servers существенно время на hotswap / redeploy (особенно редеплой!) кода в работающую JVM (JBoss, WebSphere или что угодно), сколько времени он занимает. В нормальном случае hotswap нескольких перекомпиленных файлов (с неизмененный схемой класса, а только с измененным кодом) тоже должен укладываться в 8-10 секунд.
Еще один момент, который тоже сильно тормозит компиляцию —
в некоторых организациях (у нас так было когда-то). исходники лежат в сети (домашние директории пользователей расположены на центральном файл сервере. Само по себе это не так чтобы сильно тормозит (локальный файл кеш справляется), а вот если и результирующие файлы пишутся в сеть, вот тут начинаются тормоза. Решается настройкой локальной директории для всех временных и результирующих файлов.
в некоторых организациях (у нас так было когда-то). исходники лежат в сети (домашние директории пользователей расположены на центральном файл сервере. Само по себе это не так чтобы сильно тормозит (локальный файл кеш справляется), а вот если и результирующие файлы пишутся в сеть, вот тут начинаются тормоза. Решается настройкой локальной директории для всех временных и результирующих файлов.
Здесь куда более правильное решение — использовать систему контроля версий (subversion/git).
Я не о том. Система контроля версий с этим не связана — без нее вообще нельзя.
У нас просто продукт собирается на 10+ разных вариантах юниксов, не считая виндов. Поэтому работать можно исключительно с исходниками, лежащими на сетевом диске. Иначе разработчики будут заниматься исключительно копированием и синхронизацией своих изменений. А так я редактирую исходники в одном месте, и запускаю параллельную компиляцию на нескольких платформах для проверки.
У нас просто продукт собирается на 10+ разных вариантах юниксов, не считая виндов. Поэтому работать можно исключительно с исходниками, лежащими на сетевом диске. Иначе разработчики будут заниматься исключительно копированием и синхронизацией своих изменений. А так я редактирую исходники в одном месте, и запускаю параллельную компиляцию на нескольких платформах для проверки.
А какая конфига, debug или release?
А что с precompiled headers?
Ну и про отсутствие самой интересной общей конечной диаграммки тут уже писали, да.
А что с precompiled headers?
Ну и про отсутствие самой интересной общей конечной диаграммки тут уже писали, да.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ускоряем Visual Studio, часть II. Эксперименты с компиляцией