Наши партнеры

UnixForum

Библиотека сайта rus-linux.net

Ninja

Глава 3 из книги "Производительность приложений с открытым исходным кодом".

Оригинал: Ninja
Автор: Evan Martin
Перевод: А.Панин

Выводы и альтернативные архитектуры

Время от времени в списке рассылки кто-то предлагает реализовать работу системы Ninja как постоянно находящегося в памяти демона или сервера, объединенного с системой мониторинга модификаций файлов (т.е., системой на основе inotify на платформе Linux). Все затраты времени, возникающие из-за необходимости загрузки данных и их последующей записи на диск, не будут существенны в том случае, если система Ninja будет функционировать в перерывах между сборками.

Фактически, эту архитектуру я изначально и планировал использовать для Ninja. Только после того, как я стал свидетелем первой быстрой сборки проекта, я решил, что должна быть возможность реализации функционирующей версии системы Ninja без серверного компонента. Данный подход на сегодняшний день может оказаться необходимым, так как кодовая база Chrome продолжает расти, но все же более простой подход, при котором мы повышаем скорость работы системы путем выполнения меньшего объема работы вместо использования более сложного механизма, всегда будет более предпочтительным для меня. Я надеюсь, что дополнительных реструктуризаций (таких, как изменения, которые мы провели для использования лексического анализатора или нового формата зависимостей заголовков для платформы Windows) будет вполне достаточно.

Простота является достоинством программного обеспечения; при этом вопрос всегда состоит в том, как далеко она может зайти. В рамках системы Ninja нам удалось убрать из системы сборки проектов большую часть усложняющих ее функций и передать определенные ресурсоемкие задачи другим инструментам (GYP или CMake) и именно поэтому данная система стала важной частью проектов, для которых она изначально не разрабатывалась. Надеюсь, что именно простой код системы Ninja стимулировал сторонних разработчиков - большая часть работы по поддержке систем OS X, Windows, CMake, а также реализации других возможностей была выполнена именно сторонними разработчиками. Простая семантика системы Ninja привела других разработчиков к мыслям о проведении экспериментов с целью ее повторной реализации с использованием других языков программирования (Scheme и Go, насколько мне известно).

Действительно ли миллисекунды имеют такое большое значение? При рассмотрении более важных проблем программного обеспечения беспокойство о них может оказаться глупым. Однако, после работы над проектами, которые собираются долго, мне показалось, что повышается не только продуктивность работы; быстрый цикл сборки придает ощущение легкости, которое доставляет радость при работе с проектом. А наличие кода, с которым приятно работать, является главной причиной разработки мною программного обеспечения. В этом смысле скорость имеет первоочередное значение.

Благодарности

Выражаю особую благодарность множеству разработчиков системы Ninja; имена некоторых из них вы можете найти на странице проекта Ninja на GitHub.

  1. Http://blog.chromium.org/2008/10/io-in-google-chrome.html.
  2. Http://neugierig.org/software/chromium/notes/2009/01/startup.html.
  3. Аббревиатура GYP расшифровывается как "Generate Your Projects" ("Генерируйте ваши проекты").
  4. Это тот же шаблон проектирования, который используется в Autotools: файл Makefile.am содержит список файлов исходного кода и впоследствии обрабатывается сценарием configure с целью генерации более конкретных инструкций сборки.
  5. Сам проект Chrome также развивается стремительно. На данный момент в проект вносится около 1000 изменений в неделю, большая часть из которых заключается в добавлении кода.
  6. Эта дополнительная непрямолинейность позволяет в ходе сборки корректно моделировать команды с множеством выводов.
  7. Система Ninja имеет обширный набор тестов, состоящий из 164 тестовых случаев, каждый из которых выполняется в течение секунды и это означает, что разработчики могут быть уверены в том, что изменения производительности не повлияют на корректность работы программы.
  8. На сегодняшний день в ходе сборки Chrome генерируется 10 МБ файлов .ninja.
  9. Также сохраняется информация о том, когда каждая из команд начинает и завершает свою работу, являющаяся полезной при профилировании сборок с множеством файлов.
  10. Одно из дополнительных преимуществ в данном случае было отмечено пользователями систем с многоядерными центральными процессорами и состоит в том, что их сборки стали выполняться быстрее ввиду того, что в ходе сборки Ninja потребляет относительно малый объем вычислительных ресурсов и это обстоятельство позволяет освободить ядро для выполнения команд сборки.
  11. Большая часть успешно выполняемых команд сборки не выводит какой-либо информации, поэтому это актуально только в случае параллельного неудачного завершения множества команд: их сообщения об ошибках будут выведены последовательно.
  12. Из-за этого система и называется "Ninja" ("Ниндзя"): работа выполняется незаметно и быстро.
  13. Функция stat() на платформе Windows даже медленнее, чем GetFileAttributesEx().
  14. Это актуально, когда данные находятся в дисковом кэше, так как в этом случае производительность диска не важна.

Вернуться к началу статьи.