Как заставить Windows работать так же быстро, как Linux, для компиляции C ++?

144

Я знаю, что это не столько вопрос программирования, сколько актуальный.

Я работаю над довольно крупным кроссплатформенным проектом . В Windows я использую VC ++ 2008. В Linux я использую gcc. В проекте около 40к файлов. Windows в 10-40 раз медленнее, чем Linux при компиляции и компоновке одного и того же проекта. Как я могу это исправить?

Инкрементальная сборка с одним изменением 20 секунд в Linux и> 3 минут в Windows. Зачем? Я даже могу установить «золотой» компоновщик в Linux и сократить это время до 7 секунд.

Точно так же git в 10-40 раз быстрее в Linux, чем в Windows.

В случае git возможно, что git не использует Windows оптимальным образом, но VC ++? Можно подумать, что Microsoft захочет сделать своих разработчиков максимально продуктивными, и более быстрая компиляция будет иметь большое значение для этого. Может быть, они пытаются подтолкнуть разработчиков к C #?

В качестве простого теста найдите папку с большим количеством подпапок и выполните простой

dir /s > c:\list.txt

в Windows. Сделайте это дважды и рассчитайте время второго запуска, чтобы он запускался из кеша. Скопируйте файлы в Linux и выполните 2 эквивалентных запуска и время второго запуска.

ls -R > /tmp/list.txt

У меня две рабочие станции с одинаковыми характеристиками. HP Z600 с 12 ГБ оперативной памяти, 8 ядер на 3,0 ГГц. В папке с ~ 400 КБ файлов Windows занимает 40 секунд, Linux - менее 1 секунды.

Есть ли параметр реестра, который я могу настроить для ускорения работы Windows? Что дает?


Несколько слегка релевантных ссылок, относящихся ко времени компиляции, не обязательно ввода-вывода.

gman
источник
5
Я не знаю почему, но это известная разница в характеристиках производительности Windows и Linux, Linux НАМНОГО лучше, чем Windows при работе с множеством файлов в одном каталоге, возможно, это просто NTFS против ext4 / что угодно? Также может быть, что Windows-эквивалент кеш-памяти dentry в Linux не так хорош.
Spudd86 02
75
Почему это было закрыто? «Не конструктивен» ??! Я считаю это весьма актуальным для разработчиков.
Nils
3
Этот вопрос действительно включает факты и может быть подтвержден любым количеством фактов, ссылок, чем угодно. Сама мысль о том, что название кажется спорным, не должна мешать нам обсуждать давнюю, но недостаточно обсуждаемую проблему. Я сам являюсь давним пользователем Windows, поэтому хотел бы задать этот вопрос и, надеюсь, в любое время получить продуктивные ответы. Пожалуйста, откройте вопрос повторно, если вы не можете предоставить фактических доказательств того, что вопрос по своей сути является аргументированным и не подкреплен фактами. В противном случае вы просто модератор-робот.
Халил Озгюр
2
@ HalilÖzgür: Хорошо, ваш комментарий побудил меня взглянуть на историю изменений - в исходном заголовке вопроса было что-то вроде этого. Это вполне могло быть причиной (я не голосовал за закрытие), потому что было сообщение кого-то явно оскорбленного оригинальным заголовком и начавшего бушевать, которое затем было удалено, что привело к закрытию этого вопроса. С тех пор название было отредактировано, так что я думаю, что мы в порядке. Открыт снова. Имейте в виду, что вы все равно должны стараться не обсуждать вопрос ... поскольку OP ищет ответы, предоставляет ответы, ничего больше.
BoltClock
2
Было бы здорово увидеть, как кто-то вроде @ raymond-chen поделится своими мыслями - если вопрос остается техническим и предлагает достаточно четкие данные / факты, чтобы воспроизвести проблему.
Benjamin Podszun

Ответы:

32

Если не появится заядлый хакер систем Windows, вы не получите ничего, кроме пристрастных комментариев (чего я не буду делать) и предположений (что я и собираюсь попробовать).

  1. Файловая система. Вы должны попробовать те же операции (включая операции dir) с той же файловой системой. Я наткнулся на это, которое проверяет несколько файловых систем по различным параметрам.

  2. Кеширование. Однажды я попытался запустить компиляцию в Linux на RAM-диске и обнаружил, что это медленнее, чем запуск на диске, благодаря тому, как ядро ​​заботится о кэшировании. Это веский аргумент в пользу Linux и может быть причиной того, что производительность так сильно отличается.

  3. Плохая спецификация зависимости в Windows. Возможно, спецификации зависимости хрома для Windows не так верны, как для Linux. Это может привести к ненужным компиляциям при внесении небольших изменений. Возможно, вы сможете проверить это, используя ту же цепочку инструментов компилятора в Windows.

Нуфаль Ибрагим
источник
Не могли бы вы подробнее рассказать о № 2? Это довольно удивительно - это потому, что ядро ​​не кэширует данные на RAM-диске или что-то в этом роде?
user541686
2
Если вы выделяете часть памяти как ramdisk, она не будет доступна ядру для кэширования или использования для чего-либо еще. По сути, вы заламываете ему руки и заставляете использовать меньше памяти для собственных алгоритмов. Мои знания эмпирически. Я потерял производительность, когда использовал RAMdisk для компиляций.
Нуфал Ибрагим
1
«Если не появится [эксперт по конкретной теме], вы не получите ничего, кроме пристрастных комментариев ... и домыслов»: чем это отличается от любого другого вопроса?
Дольф
1
Этот, благодаря теме Win vs. Lin, больше привлекает фанатов. Кроме того, вопрос довольно тонкий, в отличие от прямых, которые просто запрашивают команды или методы использования.
Нуфал Ибрагим
Ссылка в №1 больше не активна.
alkasm
29

Несколько идей:

  1. Отключить имена 8.3. Это может иметь большое значение для дисков с большим количеством файлов и относительно небольшим количеством папок:fsutil behavior set disable8dot3 1
  2. Используйте больше папок. По моему опыту, NTFS начинает тормозить с более чем 1000 файлов в папке.
  3. Включите параллельные сборки с MSBuild; просто добавьте переключатель «/ m», и он автоматически запустит одну копию MSBuild для каждого ядра процессора.
  4. Поместите свои файлы на SSD - очень помогает при случайном вводе-выводе.
  5. Если ваш средний размер файла намного превышает 4 КБ, подумайте о перестройке файловой системы с большим размером кластера, который примерно соответствует вашему среднему размеру файла.
  6. Убедитесь, что файлы были дефрагментированы. Фрагментированные файлы вызывают много обращений к диску, что может стоить вам более 40 раз. Используйте утилиту contig от sysinternals или встроенный дефрагментатор Windows.
  7. Если ваш средний размер файла невелик, а раздел, в котором вы находитесь, относительно заполнен, возможно, вы работаете с фрагментированной MFT, что плохо сказывается на производительности. Кроме того, файлы размером менее 1 КБ хранятся непосредственно в MFT. Упомянутая выше утилита contig может помочь, или вам может потребоваться увеличить размер MFT. Следующая команда удвоит его до 25% от объема: fsutil behavior set mftzone 2Измените последнее число на 3 или 4, чтобы увеличить размер на дополнительные 12,5%. После выполнения команды перезагрузитесь, а затем создайте файловую систему.
  8. Отключить время последнего доступа: fsutil behavior set disablelastaccess 1
  9. Отключить службу индексирования
  10. Отключите антивирусное и антишпионское ПО или, по крайней мере, установите игнорирование соответствующих папок.
  11. Поместите свои файлы на другой физический диск, отличный от ОС и файла подкачки. Использование отдельного физического диска позволяет Windows использовать параллельный ввод-вывод для обоих дисков.
  12. Посмотрите на флаги вашего компилятора. Компилятор Windows C ++ имеет множество опций; убедитесь, что вы используете только те, которые вам действительно нужны.
  13. Попробуйте увеличить объем памяти, который ОС использует для буферов выгружаемого пула (сначала убедитесь, что у вас достаточно ОЗУ): fsutil behavior set memoryusage 2
  14. Проверьте журнал ошибок Windows, чтобы убедиться, что у вас не возникают случайные ошибки диска.
  15. Взгляните на счетчики производительности, связанные с физическим диском, чтобы узнать, насколько загружены ваши диски. Большая длина очереди или большое время на передачу - плохие признаки.
  16. Первые 30% разделов диска намного быстрее, чем остальной диск, с точки зрения времени необработанной передачи. Более узкие разделы также помогают минимизировать время поиска.
  17. Вы используете RAID? В таком случае вам может потребоваться оптимизировать выбор типа RAID (RAID-5 плохо подходит для операций с большим объемом записи, таких как компиляция).
  18. Отключите все службы, которые вам не нужны
  19. Папки дефрагментации: скопируйте все файлы на другой диск (только файлы), удалите исходные файлы, скопируйте все папки на другой диск (только пустые папки), затем удалите исходные папки, дефрагментируйте исходный диск, сначала скопируйте структуру папок обратно , затем скопируйте файлы. Когда Windows создает большие папки по одному файлу за раз, папки становятся фрагментированными и медленными. ("contig" здесь тоже должен помочь)
  20. Если вы ограничены вводом-выводом и у вас есть свободные циклы ЦП, попробуйте включить сжатие диска. Он может обеспечить значительное ускорение для файлов с высокой степенью сжатия (например, исходного кода) с некоторыми затратами на процессор.
RickNZ
источник
1
Даже если бы вы сделали все это, вы бы не приблизились к производительности Linux. Попробуйте выполнить приведенный ниже тест и опубликуйте время, если вы не согласны.
b7kich
6
Нам нужен лучший тест. Измерение времени, необходимого для перечисления папки, не очень полезно, ИМО. NTFS оптимизирована для поиска одного файла со структурой btree. В Linux (последний раз я смотрел) приложение может читать всю папку с помощью одного системного вызова и полностью перебирать получившуюся структуру в пользовательском коде; Windows требует отдельного системного вызова для каждого файла. В любом случае компиляторам не нужно читать всю папку ...
RickNZ
3
Тогда то, что вы описываете, и есть проблема. Выбор другого теста не решает проблему - вы просто отводите взгляд.
b7kich
2
Вопрос был об оптимизации времени компиляции. Время перечисления папок не влияет на время компиляции в Windows, даже с десятками тысяч файлов в папке.
RickNZ
1
После внесения некоторых изменений, предложенных выше, второй запуск "ls -R" для хромового дерева занимает у меня 4,3 секунды (против 40 секунд в OP). "dir / s" занимает около секунды. Переход на SSD не помог только для перечисления, но я подозреваю, что это поможет при компиляции.
RickNZ
25

NTFS всегда экономит время доступа к файлам. Вы можете попробовать отключить его: «fsutil behavior set disablelastaccess 1» (перезапуск)

Agent_L
источник
6
Тестирование сократило на 4 секунды по сравнению с предыдущими 36. Все еще отвратительно по сравнению с 0,6 секунды на моей Linux VM
b7kich
21

Проблема с Visual C ++, насколько я могу судить, заключается в том, что оптимизация этого сценария не является приоритетом для команды компиляторов. Их решение состоит в том, что вы используете их предварительно скомпилированный заголовок. Это то, что сделали конкретные проекты Windows. Он не портативный, но работает.

Кроме того, в Windows у вас обычно есть антивирусные сканеры, а также инструменты восстановления системы и поиска, которые могут полностью испортить время сборки, если они будут отслеживать вашу папку сборки за вас. Windows 7 Resouce Monitor поможет вам обнаружить это. У меня есть ответ с некоторыми дополнительными советами по оптимизации времени сборки vc ++, если вам действительно интересно.

Сообщество
источник
18

Трудность с этим связана с тем, что C ++ имеет тенденцию распространяться и процесс компиляции на множество небольших отдельных файлов. В этом Linux хорош, а Windows - нет. Если вы хотите создать действительно быстрый компилятор C ++ для Windows, постарайтесь сохранить все в ОЗУ и как можно меньше касаться файловой системы.

Таким же образом вы сделаете более быструю цепочку компиляции Linux C ++, но в Linux это менее важно, потому что файловая система уже выполняет большую часть этой настройки за вас.

Причина этого кроется в культуре Unix: исторически производительность файловой системы была гораздо более приоритетной в мире Unix, чем в Windows. Нельзя сказать, что это не было приоритетом в Windows, просто в Unix это был более высокий приоритет.

  1. Доступ к исходному коду.

    Вы не можете изменить то, что не можете контролировать. Отсутствие доступа к исходному коду Windows NTFS означает, что большая часть усилий по повышению производительности была направлена ​​на улучшение оборудования. То есть, если производительность низкая, вы можете обойти проблему, улучшив оборудование: шину, носитель данных и так далее. Вы можете сделать так много только в том случае, если вам нужно обойти проблему, а не исправить ее.

    Доступ к исходному коду Unix (даже до открытия исходного кода) был более распространен. Следовательно, если вы хотите повысить производительность, вы должны сначала решить эту проблему в программном обеспечении (дешевле и проще), а затем в оборудовании.

    В результате в мире много людей, получивших докторские степени, изучив файловую систему Unix и найдя новые способы повышения производительности.

  2. Unix имеет тенденцию к созданию множества маленьких файлов; Windows стремится к нескольким (или одному) большим файлам.

    Приложения Unix, как правило, работают с множеством небольших файлов. Подумайте о среде разработки программного обеспечения: множество небольших исходных файлов, каждый со своей целью. Последний этап (связывание) действительно создает один большой файл, но это небольшой процент.

    В результате Unix имеет высоко оптимизированные системные вызовы для открытия и закрытия файлов, сканирования каталогов и т. Д. История исследовательских работ по Unix насчитывает десятилетия оптимизации файловой системы, в ходе которой было уделено много внимания улучшению доступа к каталогам (поиск и полное сканирование каталогов), первоначального открытия файлов и т. Д.

    Приложения Windows, как правило, открывают один большой файл, держат его открытым в течение долгого времени, а после завершения закрывают. Подумайте о MS-Word. msword.exe (или что-то еще) открывает файл один раз и добавляет его на несколько часов, обновляет внутренние блоки и так далее. Оптимизация открытия файла приведет к потере времени.

    История тестирования и оптимизации Windows связана с тем, насколько быстро можно читать или записывать длинные файлы. Вот что оптимизируется.

    К сожалению, разработка программного обеспечения склоняется к первой ситуации. Черт возьми, лучшая система обработки текстов для Unix (TeX / LaTeX) поощряет вас помещать каждую главу в отдельный файл и # включать их все вместе.

  3. Unix ориентирован на высокую производительность; Windows ориентирована на взаимодействие с пользователем

    Unix запускается в серверной: нет пользовательского интерфейса. Единственное, что видят пользователи, - это скорость. Поэтому скорость - приоритет.

    Windows запускалась на рабочем столе: пользователей заботит только то, что они видят, и они видят пользовательский интерфейс. Следовательно, на улучшение пользовательского интерфейса тратится больше энергии, чем на производительность.

  4. Экосистема Windows зависит от запланированного устаревания. Зачем оптимизировать программное обеспечение, если до нового оборудования осталось всего год или два?

    Я не верю в теории заговора, но если бы верил, я бы отметил, что в культуре Windows меньше стимулов для повышения производительности. Бизнес-модели Windows зависят от людей, покупающих новые машины, как часы. (Вот почему на котировки акций тысяч компаний влияет задержка поставки операционной системы MS или пропуск даты выпуска микросхемы Intel.) Это означает, что есть стимул решать проблемы производительности, говоря людям покупать новое оборудование; не за счет улучшения реальной проблемы: медленных операционных систем. Unix пришла из академических кругов, где бюджет ограничен, и вы можете получить докторскую степень, изобретя новый способ ускорить файловые системы; редко кто-то из академических кругов получает баллы за решение проблемы путем выдачи заказа на поставку.

    Кроме того, поскольку Unix является открытым исходным кодом (даже если его не было, каждый имел доступ к исходному тексту), любой скучающий аспирант может прочитать код и прославиться, улучшив его. Этого не происходит в Windows (у MS действительно есть программа, которая дает ученым доступ к исходному коду Windows, но ею редко пользуются). Взгляните на эту подборку документов о производительности, связанных с Unix: http://www.eecs.harvard.edu/margo/papers/ или посмотрите историю статей Остерхауса, Генри Спенсера или других. Черт возьми, одним из крупнейших (и наиболее приятных для просмотра) споров в истории Unix был спор между Остерхаусом и Зельцером http://www.eecs.harvard.edu/margo/papers/usenix95-lfs/supplement/rebuttal. html Вы не увидите такого рода вещей в мире Windows. Вы можете увидеть, как поставщики напирают друг на друга, но в последнее время это, похоже, стало намного реже, поскольку все нововведения, по всей видимости, находятся на уровне органов стандартизации.

Вот как я это вижу.

Обновление: если вы посмотрите на новые цепочки компиляторов, выпускаемые Microsoft, вы будете очень оптимистичны, потому что многое из того, что они делают, упрощает сохранение всей цепочки инструментов в ОЗУ и повторение меньшего количества работы. Очень впечатляющий материал.

TomOnTime
источник
6
Сказать, что причина «культурная, а не техническая», на самом деле не ответить на вопрос. Очевидно, что существует одна или несколько основных технических причин, по которым некоторые операции в Windows выполняются медленнее, чем в Linux. Теперь культурные проблемы могут объяснить, почему люди принимали технические решения, которые они приняли; но это технический сайт вопросов и ответов. Ответы должны охватывать технические причины, по которым одна система работает медленнее, чем другая (и что можно сделать для улучшения ситуации), а не бездоказательные предположения о культуре.
Брайан Кэмпбелл,
Похоже, здесь не так много технической информации. В основном косвенные. Я думаю, что единственный способ получить реальную техническую информацию - это посмотреть на различия между двумя компиляторами, системами сборки и т. Д. И т. Д.
surfasb
Приложения Windows обычно открывают один большой файл и долгое время удерживают его открытым - многие приложения UNIX делают это. Серверы, мой Emacs и т. Д.
Нуфал Ибрагим
Я не думаю, что emacs держит файлы открытыми в течение длительного времени, независимо от того, большие они или маленькие. Конечно, он не записывает в середину файла, обновляя его, как это сделала бы база данных.
TomOnTime
… И серверы этого тоже не делают. Их функции в системах * nix обычно разделены на множество небольших модулей, при этом ядро ​​сервера по существу является пустой оболочкой.
spectras
17

Я лично обнаружил, что запуск виртуальной машины Windows на linux позволил устранить большую часть медленного ввода-вывода в Windows, вероятно, потому, что linux vm выполнял много кэширования, чего не было в самой Windows.

Благодаря этому я смог сократить время компиляции большого (250Kloc) проекта C ++, над которым я работал, с примерно 15 минут до примерно 6 минут.

лягушка
источник
шутки в сторону? Вы имеете в виду, что я должен попробовать использовать виртуальную машину в качестве разработчика? Звучит странно ... какую виртуальную машину вы используете?
Мартин Бука Везер,
8
Я протестировал описанный выше сценарий на виртуальной машине Ubuntu 11.04, работающей на моей рабочей станции с Windows 7. 0,6 секунды для виртуальной машины linux, 36 секунд для моей рабочей станции с Windows
b7kich
2
Если вы используете виртуальный бокс и настраиваете общий диск, вы можете существенно ускорить компиляцию бесплатно.
orlp
1
Формулировка здесь очень сбивает с толку, но я предполагаю, что это означает виртуальную машину под управлением Windows, работающую под управлением Linux, а не виртуальную машину под управлением Windows, размещенную в Linux ... что интересно, но мое первое - буквальное - чтение этого предположило, что запуск Windows в ВМ , размещенного на Linux для обобщит привело к более высокой скорости , чем при запуске Windows , изначально - и что бы уже действительно было что - то.
underscore_d
@underscore_d, я кое- что видел , где Windows на виртуальной машине работает намного быстрее, чем на реальном оборудовании. Вероятно, потому, что Linux сообщил Windows, что он работает на реальном диске, в то время как Linux фактически выполнял агрессивное кэширование за кулисами. Например, установка Windows на виртуальную машину также прошла невероятно быстро. Это было еще во времена XP, но я был бы удивлен, если бы сегодня была большая разница.
Проф. Фалькен
7

Инкрементное связывание

Если решение VC 2008 настроено как несколько проектов с выходными файлами .lib, вам необходимо установить «Использовать входы зависимостей библиотеки»; это делает ссылку компоновщика непосредственно на файлы .obj, а не на .lib. (И фактически делает его постепенным связыванием.)

Производительность обхода каталогов

Немного несправедливо сравнивать сканирование каталогов на исходном компьютере со сканированием вновь созданного каталога с такими же файлами на другом компьютере. Если вам нужен эквивалентный тест, вам, вероятно, следует сделать еще одну копию каталога на исходной машине. (Это все еще может быть медленным, но это может быть связано с множеством причин: фрагментацией диска, короткими именами файлов, фоновыми службами и т. Д.) Хотя я думаю, что проблемы производительности dir /sбольше связаны с записью вывода, чем с измерением фактического файла производительность обхода. Даже dir /s /b > nulна моей машине с огромным каталогом работает медленно.

MSN
источник
6

Я почти уверен, что это связано с файловой системой. Я работаю над кроссплатформенным проектом для Linux и Windows, где весь код является общим, за исключением случаев, когда платформенно-зависимый код абсолютно необходим. Мы используем Mercurial, а не git, поэтому «Linuxness» git не применяется. Внесение изменений из центрального репозитория в Windows занимает вечность по сравнению с Linux, но я должен сказать, что наши машины с Windows 7 работают намного лучше, чем машины с Windows XP. Компиляция кода после этого в VS 2008 еще хуже. Дело не только в hg; CMake также работает намного медленнее в Windows, и оба этих инструмента используют файловую систему больше, чем что-либо еще.

Проблема настолько серьезна, что большинство наших разработчиков, работающих в среде Windows, больше даже не утруждают себя инкрементными сборками - они обнаруживают, что сборка единства выполняется быстрее.

Кстати, если вы хотите резко снизить скорость компиляции в Windows, я бы предложил вышеупомянутую сборку единства. Трудно правильно реализовать в системе сборки (я сделал это для нашей команды в CMake), но когда это сделано, автоматически ускоряет работу наших серверов непрерывной интеграции. В зависимости от того, сколько двоичных файлов выдает ваша система сборки, вы можете получить улучшение на 1–2 порядка. Ваш пробег может отличаться. В нашем случае я думаю, что это ускорило сборку Linux втрое, а сборку Windows примерно в 10 раз, но у нас много общих библиотек и исполняемых файлов (что снижает преимущества единой сборки).

Атила Невес
источник
5

Как вы строите свой большой кроссплатформенный проект? Если вы используете общие make-файлы для Linux и Windows, вы можете легко снизить производительность Windows в 10 раз, если make-файлы не предназначены для быстрой работы в Windows.

Я только что исправил некоторые make-файлы кроссплатформенного проекта, используя общие (GNU) make-файлы для Linux и Windows. Make запускает sh.exeпроцесс для каждой строки рецепта, вызывая разницу в производительности между Windows и Linux!

Согласно документации GNU make

.ОНЕШЕЛЛ:

должен решить проблему, но эта функция (в настоящее время) не поддерживается для Windows make. Так что переписывание рецептов в отдельные логические строки (например, добавление; \ или \ в конец строк текущего редактора) сработало очень хорошо!

V15I0N
источник
4

ИМХО, все дело в производительности дискового ввода-вывода. По порядку величины предполагается, что многие операции выполняются на диске под Windows, тогда как под Linux они выполняются в памяти, т.е. Linux лучше кэширует. Лучшим вариантом под Windows будет перемещение файлов на быстрый диск, сервер или файловую систему. Рассмотрите возможность покупки твердотельного накопителя или перемещения файлов на RAM-диск или быстрый сервер NFS.

Я провел тесты обхода каталогов, и результаты очень близки к заявленному времени компиляции, предполагая, что это не имеет никакого отношения к времени обработки ЦП или алгоритмам компилятора / компоновщика.

Измеренное время, как предложено выше при обходе дерева каталогов хрома:

  • Windows Home Premium 7 (8 ГБ ОЗУ) в NTFS: 32 секунды
  • Ubuntu 11.04 Linux (2 ГБ ОЗУ) в NTFS: 10 секунд
  • Ubuntu 11.04 Linux (2 ГБ ОЗУ) на ext4: 0,6 секунды

Для тестов вытащил исходники хрома (оба под win / linux)

git clone http://github.com/chromium/chromium.git 
cd chromium
git checkout remotes/origin/trunk 

Чтобы измерить время, которое я бежал

ls -lR > ../list.txt ; time ls -lR > ../list.txt # bash
dir -Recurse > ../list.txt ; (measure-command { dir -Recurse > ../list.txt }).TotalSeconds  #Powershell

Я отключил временные метки доступа, свой антивирусный сканер и увеличил настройки кеш-менеджера под Windows (> 2 ГБ ОЗУ) - все без каких-либо заметных улучшений. Дело в том, что Linux «из коробки» работал в 50 раз лучше, чем Windows с четвертью ОЗУ.

Для тех, кто хочет утверждать, что цифры неверны - по какой-либо причине - попробуйте и опубликуйте свои выводы.

b7kich
источник
1
После выполнения некоторых настроек, которые я описываю в своем ответе для Windows, выполнение теста "ls -lR" выше на дереве хрома заняло 19,4 секунды. Если я вместо этого использую «ls -UR» (который не получает статистику файлов), время упадет до 4,3 секунды. Перемещение дерева на SSD ничего не ускорило, поскольку данные файла кэшируются ОС после первого запуска.
RickNZ
Спасибо, что поделился! Несмотря на значительное улучшение в 10 раз по сравнению со сценарием Windows 7 «из коробки», это все равно в 10 раз хуже, чем для Linux / ext4.
b7kich
Я думал, что цель OP - улучшить производительность Windows, верно? Кроме того, как я писал выше, "dir / s" выполняется примерно за секунду.
RickNZ
3

Попробуйте использовать jom вместо nmake

Получите здесь: https://github.com/qt-labs/jom

Дело в том, что nmake использует только одно из ваших ядер, jom - это клон nmake, который использует многоядерные процессоры.

GNU make делает это из коробки благодаря опции -j, что может быть причиной его скорости по сравнению с Microsoft nmake.

jom работает, выполняя параллельно разные команды make на разных процессорах / ядрах. Попробуйте сами почувствуйте разницу!

OpenNingia
источник
1

Я хочу добавить только одно наблюдение с использованием Gnu make и других инструментов из инструментов MinGW в Windows: они, похоже, разрешают имена хостов, даже если инструменты не могут даже общаться через IP. Я предполагаю, что это вызвано какой-то процедурой инициализации среды выполнения MinGW. Использование локального DNS-прокси помогло мне улучшить скорость компиляции с помощью этих инструментов.

Раньше у меня сильно болела голова, потому что скорость сборки упала примерно в 10 раз, когда я открывал VPN-соединение параллельно. В этом случае все эти DNS-запросы проходили через VPN.

Это наблюдение может также относиться к другим инструментам сборки, не только на основе MinGW, и тем временем оно могло быть изменено в последней версии MinGW.

V15I0N
источник
0

Недавно я мог заархивировать другой способ ускорить компиляцию примерно на 10% в Windows с помощью Gnu make, заменив mingw bash.exe версией из win-bash

(Win-bash не очень удобен для интерактивного редактирования.)

V15I0N
источник