Разработчик ядра Windows NT объяснил причины низкой производительности ОС

Один из программистов компании Microsoft анонимно выступил на форуме Hacker News и выдал интересные подробности о процессе разработки ядра NT. Своим сообщением он хотел подтвердить тезис о том, что ядро неэффективно и во многом уступает по производительности другим ОС: см. оригинальное сообщение (автор удалил его, испугавшись резких формулировок) и копию.

Причина проблем, по словам сотрудника Microsoft, социальная. Дело в том, что разработчики не вносят в ядро таких оптимизаций, которые мы видим в мире Linux. В компании Microsoft никто не будет хвалить программиста, если он оптимизировал какой-то процесс на 5%, если это не входит в сферу его основных обязанностей. Такая оптимизация никому не интересна. Только в случае какого-то очень существенного прогресса работу программиста могут заметить в соседних командах разработки, что положительно отразиться на его карьере. Но это скорее исключение, чем правило. Нет никакого стимула принимать изменения из-за пределов своей команды разработки.

В Microsoft не существует программы по систематическому улучшению производительности Windows. Во времена Windows XP компания начала уделять большое внимание безопасности, потому что с этим обнаружились серьёзные проблемы. Однако на производительность никто не обращал и не обращает особого внимание.

Ещё одна проблема в ухудшении ситуации с производительностью ОС — в утечке самых талантливых кадров. Google и другие компании Кремниевой долины активно охотятся за одаренными программистами и не стесняются переманивать их из других компаний. Из-за текучки кадров новые разработчики предпочитают реализовывать новые функции вместо оптимизации старых. Именно в этом причина появления PowerShell: многие хотели улучшить cmd.exe, но не имели возможности.

В качестве конкретных примеров разработчик называет следующее:

«Нам нельзя трогать именованные каналы. Лучше добавим %INTERNAL_NOTIFICATION_SYSTEM%! И пусть она будет несовместима с почти всеми другими именованными примитивами NT.

Мы не можем показывать %INTERNAL_NOTIFICATION_SYSTEM% остальному миру, потому что не хотим заниматься бумажной работой и терять продажи, ведь сейчас публично доступны только интерфейса Win32 APIs эпохи 90-х.

Мы не можем трогать DCOM. Так что создадим ещё один %C#_REMOTING_FLAVOR_OF_THE_WEEK%!

XNA. Что тут ещё сказать?

Зачем кому-то нужен формат архивирования с поддержкой файлов больше 2 ГБ?

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

Нельзя трогать Source Depot, так что давайте вместе хакнем SDX (Secure Document Exchange)!

Нельзя трогать SDX, так что давайте притворяться в течение четырёх релизов, что мы переходим на TFS (Team Foundation Server), а сами ничего не будем менять!

Господи, код NTFS — это багровый роман ужасов, написанный под опиумом в средневековье, где используются глобальные рекурсивные блокировки и контроль потока со структурной обработкой исключений (SEH). Давайте вместо неё напишем ReFs. (И да, начнем с копипаста исходников NTFS и удаления половины функциональности! Теперь добавим контрольные суммы, потому что контрольные суммы это круто, и с контрольными суммами мы почти так же круты, как ZFS, верно? И вообще, кому нужны квоты?)

Мы вообще не в силах реализовать поддержку C11, а шаблоны с переменным числом аргументов слишком сложны, чтобы внедрить их за год. (Но смотрите, мы превратили «^» в оператор указателя с подсчитанными ссылок! Ой, а что такое подсчёт ссылок?)».

Осторожно, хабр!