Почему создание является новым процессом, более дорогим в Windows, чем Linux?

mweerden: NT был разработан для многопользовательского со дня один, таким образом, это не действительно причина. Однако Вы правы относительно того создания процесса, играет меньше важная роль на NT, чем на Unix, поскольку NT, в отличие от Unix, способствует многопоточности по многопроцессорной обработке.

Rob, это верно, что ветвление является относительно дешевым, когда COW используется, но на самом деле, ветвление главным образом сопровождается должностным лицом. И должностное лицо должно загрузить все изображения также. Обсуждение выполнения ветвления поэтому является только частью истины.

При обсуждении скорости создания процесса, это - вероятно, хорошая идея различать NT и Windows/Win32. Насколько NT (т.е. само ядро) идет, я не думаю создание процесса (NtCreateProcess) и распараллеливаю создание (NtCreateThread), значительно медленнее как в среднем Unix. Там мог бы немного больше продолжаться, но я не вижу основные основания для различия в производительности здесь.

при рассмотрении Win32, однако, Вы заметите, что он добавляет довольно мало служебные для обработки создания. Для одного это требует, чтобы CSRSS был уведомлен о создании процесса, которое включает LPC. Это требует, по крайней мере, kernel32 быть загруженным дополнительно, и это должно выполнить много дополнительных бухгалтерских объектов работы, которые будут сделаны, прежде чем процесс будет считаться законченным процессом Win32. И давайте не забывать обо всех дополнительных издержках, наложенных путем парсинга деклараций, проверки, требует ли изображение контейнера compatbility, проверяя, применяются ли политики ограничения программного обеспечения, yada yada.

Однако я вижу полное замедление в сумме всех тех небольших вещей, которые должны быть сделаны в дополнение к необработанному созданию процесса, пространства ВА и начального потока. Но, как сказано в начале - из-за одобрения многопоточности по многозадачности, единственное программное обеспечение, которое серьезно затронуто этим дополнительным расходом, является плохо портированным программным обеспечением Unix. Хотя этот sitatuion изменяется, когда программное обеспечение как Chrome и IE8 внезапно открывает вновь преимущества многопроцессорной обработки и начинает часто запускать и процессы разрушения...

В дополнение к ответу Rob Walker: В наше время у Вас есть вещи как Собственная Библиотека Потока POSIX - если Вы хотите. Но в течение долгого времени единственный способ "делегировать" работу в мире Unix состоял в том, чтобы использовать ветвление () (и это все еще предпочтено во многих, многих обстоятельствах). например, некоторый сервер сокета

socket_accept()
fork()
if (child)
    handleRequest()
else
    goOnBeingParent()

Поэтому реализация ветвления должна была быть быстрой, и оптимизация партий реализовывалась со временем. Microsoft поддержала CreateThread или даже волокна вместо того, чтобы создать новые процессы и использование межпроцессного взаимодействия. Я думаю, что не "справедливо" сравнить CreateProcess для разветвления, так как они не являются взаимозаменяемыми. Вероятно, более уместно сравнить ветвление/должностное лицо с CreateProcess.

Добавление к тому, что заявил мировой судья: большинство издержек принадлежит запуску Win32 для процесса.

ядро Windows NT на самом деле поддерживает ветвление COW. SFU (среда UNIX Microsoft для Windows) использует их. Однако Win32 не поддерживает ветвление. Процессы SFU не являются процессами Win32. SFU является ортогональным к Win32: они - оба подсистемы среды, основывался на том же ядре.

В дополнение к LPC из процесса звонит в CSRSS, в XP и позже существует из вызова процесса к механизму совместимости приложения для нахождения программы в базе данных совместимости приложения. Этот шаг вызывает достаточно служебное, что Microsoft предоставляет возможность групповой политики к , отключают механизм совместимости на WS2003 по причинам производительности.

библиотеки времени выполнения Win32 (kernel32.dll, и т.д.) также делают много чтений реестра и инициализации на запуске, которые не относятся к UNIX, SFU или собственным процессам.

Собственные процессы (без подсистемы среды) очень быстры для создания. SFU делает намного меньше, чем Win32 для создания процесса, таким образом, его процессы также быстры для создания.

ОБНОВЛЕНИЕ НА 2019: добавьте LXSS: Windows Subsystem для Linux

, Заменяющего SFU для Windows 10, является подсистемой среды LXSS. Это - 100%-й привилегированный режим и не требует, любой изо что IPC, которую Win32 продолжает иметь. Syscall для этих процессов направлен непосредственно к lxss.sys/lxcore.sys, таким образом, ветвление () или другое создание процесса называет только затраты 1 системным вызовом создателя, общего количества. [Область данных звонила, экземпляр] отслеживает все LX процессов, потоки и состояние во время выполнения.

процессы LXSS основаны на собственных процессах, не процессах Win32. Весь Win32 определенный материал как механизм совместимости не занят вообще.

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

Основанные на Unix системы первоначально были многопользовательскими системами и серверами. Специально для последнего весьма распространено иметь процессы (например, почта или http демоны), которые отделяют процессы для обработки определенных заданий (например, заботящийся об одном входящем соединении). Важным фактором в выполнении этого является дешевое fork метод (что, как упомянуто Rob Walker ( 47865 ), первоначально использует ту же память для недавно созданного процесса), который очень полезен, поскольку новый процесс сразу имеет всю информацию, этому нужно.

ясно, что, по крайней мере, исторически потребность в Основанных на Unix системах для имения быстрого создания процесса намного больше, чем для систем Windows. Я думаю, что это все еще имеет место, потому что Основанные на Unix системы являются все еще очень ориентированным процессом, в то время как Windows, из-за его истории, вероятно, был большим количеством ориентированного потока (потоки, являющиеся полезным для подавания быстро реагирующих заявок).

Правовая оговорка: я ни в коем случае не эксперт по этому вопросу, поэтому простите мне, если я понял его превратно.

Мм, кажется, существует многое из, "его лучше этот путь" вид продолжения выравнивания.

я думаю, что люди могли извлечь выгоду из чтения "Showstopper"; книга о разработке Windows NT.

целая причина сервисы, выполненные как DLL в одном процессе на Windows NT, состояли в том, что они были слишком медленными как отдельные процессы.

, Если бы Вы спустились и грязный, Вы нашли бы, что библиотека, загружающая стратегию, является проблемой.

На Нельдах (в целом) Общие библиотеки сегменты кода (DLL) на самом деле совместно используются.

Windows NT загружает копию DLL для каждого процесса, becauase это управляет сегментом кода библиотеки (и сегмент исполняемого кода) после загрузки. (Говорит его, где Ваши данные?)

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

Так, процесс NT создает, является на самом деле довольно дорогим. И на вниз стороне, это не делает заметное сохранение DLL в памяти, но шанс для проблем межзависимости приложений.

Иногда это платит в разработке, чтобы отступить и сказать, "теперь, если бы мы собирались разработать это для реального всасывания, на что это было бы похоже?"

я работал со встроенной системой, которая была довольно темпераментной когда-то давно, и однажды посмотрела на него и поняла, что это был магнетрон полости с электроникой в микроволновом резонаторе. Мы сделали его намного более стабильным (и меньше как микроволна) после этого.

Все, что плюс существует то, что на машине Win по всей вероятности антивирусное программное обеспечение умрет во время CreateProcess... Это обычно - самое большое замедление.

Unix имеет системный вызов 'ветвления', который 'разделяет' текущий процесс на два и дает Вам второй процесс, который идентичен первому (по модулю возврат из вызова ветвления). Так как адресное пространство нового процесса уже в порядке, это, должно быть более дешевым, чем вызов 'CreateProcess' в Windows и наличии его загружает изображение exe, связанные dlls, и т.д.

В ветвлении случаются, ОС может использовать семантику 'копии на записи' для страниц памяти, связанных с обоими новыми процессами, чтобы гарантировать, что каждый получает их собственную копию страниц, которые они впоследствии изменяют.

Краткий ответ - «программные уровни и компоненты».

Архитектура Windows SW имеет несколько дополнительных уровней и компонентов, которых нет в Unix или которые упрощены и обрабатываются внутри ядро в Unix.

В Unix, fork и exec являются прямыми вызовами ядра.

В Windows API ядра не используется напрямую, есть win32 и некоторые другие компоненты поверх него, поэтому создание процесса должно пройти через дополнительные уровни, а затем должен запуститься новый процесс или соединиться с этими слоями и компонентами.

В течение некоторого времени исследователи и корпорации пытались разбить Unix примерно таким же способом, обычно основывая свои эксперименты на ядре Mach ; хорошо известным примером является OS X. . Однако каждый раз, когда они пытаются,