В настоящей статье я исследую человеческие и машинные аспекты задержки при печатании (вводе с клавиатуры или «запаздывание ввода») и представляю экспериментальные данные по задержке при работе с популярными редакторами текста и кода.
С недавних пор Задержка стала горячей темой в компьютерном мире — сейчас есть клавиатуры с малой задержкой, мониторы на 144 Гц, специальные технологии, уменьшающие время задержки (как, например, FreeSync или G-Sync), интересующиеся этим сообщества и прочее и прочее. Конечно, часть этой моды создана маркетингом, но правда в том, что малая задержка стала возможной и желательной.
Очевидно, что геймеры — первые, кто выигрывает от таких улучшений. В некоторых областях, таких как виртуальная реальность, задержка оказывается решающим фактором, даже когда речь идёт об одной миллисекунде. Но что сказать о программистах? Нужно ли нам «печатать с удовольствием», чтобы «разрабатывать с удовольствием»? Давайте разберёмся.
Содержание:
1. Сторона человека
1.1. Обратная связь
1.2. Моторный навык
1.3. Внутренняя модель
1.4. Мультисенсорная интеграция
1.5. Эффекты
2. Сторона машины
2.1. Входная задержка
2.2. Задержка обработки
2.3. Выходная задержка
2.4. Полная задержка
3. Сравнительные тесты редакторов
3.1. Конфигурация
3.2. Методология
3.3. Windows
3.4. Linux
3.5. VirtualBox
4. Выводы
5. Ссылки
1. Сторона человека
Задержкой при вводе с клавиатуры называется интервал времени между нажатием клавиши и соответствующим обновлением экрана. Звучит просто, но не заблуждайтесь: её воздействие на процесс ввода с клавиатуры является довольно сложным, поскольку такое печатание является удивительным проявлением согласованных действий нашего тела и нервной системы (по крайней мере, с технической точки зрения).
Начнём с основ — стоит ли, вообще, беспокоиться о задержке? У нас ведь нет какой-то спешки, мы можем просто печатать, что требуется, а результат проверить позже. Несколько секунд ничего не решают, так ведь? Не совсем.
1.1. Обратная связь
Человек не «просто печатает», что желает; нам нужна обратная связь, чтобы выполнять эту задачу, поскольку наши чувства образуют т.н. замкнутый контур управления с нашими движениями. Зрительный образ — не только результат ввода; он является неотъемлемой частью процесса.
Чем более полную обратную связь мы имеем при работе с клавиатурой (печатании), тем лучше. В принципе, можно печатать с закрытыми глазами. Мы можем продолжать печатать, даже если заткнём уши, полагаясь только на тактильные ощущения от пальцев. Однако, если мы заблокируем этот последний канал обратной связи, то ввод с клавиатуры станет невозможным. Поскольку зрительный вид ощущения является доминирующим (информация от других органов чувств обычно подстраивается под зрение) и представляет собой единственный способ получения достоверных данных об ошибках ввода, то зрительная обратная связь имеет большое значение.
Уменьшение задержки ведёт к «укорачиванию» петли обратной связи, благодаря чему ввод идёт легче, с большей скоростью и точностью. Пока неплохо, но где разумная граница? В конце концов, человек реагирует невероятно медленно — «путь туда и обратно» от чувств к сознанию и затем обратно к мышцам занимает около 200 мс! Несомненно, реакцию можно тренировать, и она различная у людей, но некоторая сравнительно маленькая задержка, как, например, 100 мс, вроде бы, хороший вариант, не так ли? Ничуть.
1.2. Моторный навык
Вспомните ваши первые попытки использовать компьютерную клавиатуру. Скорее всего, вам требовались минуты, чтобы нажать надлежащую клавишу и затем проверить результат на экране; этот процесс требовал всей вашей сосредоточенности. Однако пролетели месяцы и годы, вы теперь вводите на клавиатуре потрясающе быстро и полуавтоматически — вы уже не думаете о каких-то специфических клавишах и, возможно, уже, вообще, не смотрите на клавиатуру («слепая печать»). Практика сказывается. Такой процесс называется «приобретение моторных навыков» (или усвоение двигательного навыка (моторное научение)). Когда умение достигает автономной фазы, задача может быть выполнена «автоматически» без привлечения какого-либо внимания на её выполнение.
Формально говоря, печатание (ввод на клавиатуре) — это процесс управления движением, осуществляемым моторной системой человека. Поскольку печатание (ввод на клавиатуре) является мелкой моторикой (происходят скоординированные движения мелких мускулов), оно сильно зависит от обратной связи. Однако эта обратная связь обрабатывается на уровне подсознания, поэтому мы необязательно будем осознавать задержку, испытывая в то же время её серьёзное отрицательное воздействие. Время реакции человека имеет значение только для исправления ошибок.
Но даже полуавтоматические процессы ограничены зрительной задержкой (pdf-файл), и любая обратная связь хороша, только если мы можем использовать её. Системе зрения человека требуется около 40 мс, чтобы обработать ввод. Это значение также зависит от многих факторов, от конкретного человека и может быть улучшено тренировкой. Делаем вывод: задержка менее 20 мс была бы приемлемой, так? Не совсем.
1.3. Внутренняя модель
Прежде всего, уточним, что любая «внешняя» задержка добавляется к зрительной задержке, а не накладывается на неё, т.е. любая задержка имеет значение. Но можно аргументировать, что значение около 20 мс, всё равно, сравнительно мало. Хорошо, но моторная система человека знает несколько ловких трюков, чтобы реагировать быстрее.
Чтобы противодействовать входным задержкам в сенсорных органах и нервной системе, система управления движением человека использует специальный нервный процесс, известный как внутренняя модель. Этот процесс может имитировать отклик (реакцию) управляемой системы ещё до получения сигналов обратной связи — использование опережающего моделирования процесса. Дополнительная инверсная модель предназначена для прогнозирования отклика (реакции) управляемой системы на базе текущей обратной связи.
Задержка не влияет на контур обратной связи непосредственно, она воздействует, скорее, на внутреннюю модель процесса печатания. Прямая и инверсная модели используются в комбинации с некоторыми контурами внутренней обратной связи, образуя нелинейную систему. В результате даже малые задержки в сигналах обратной связи могут привести к значительным нарушениям при вводе на клавиатуре (печатании).
Отдельно от внутренней модели существует другой процесс, на который неблагоприятно влияет зрительная задержка, — мультисенсорная интеграция.
1.4. Мультисенсорная интеграция
Зрительный образ является не единственным видом обратной связи при печатании на клавиатуре: мы можем также слышать звуки при нажатии на клавиши, ощущать давление на наши пальцы, воспринимать положение наших рук и пальцев (т.н. проприоцепция).
Каждое из этих ощущений обрабатывается отдельно, и нервная система определяет, использовать или нет те или иные группы сигналов. Эта задача известна как проблема связывания и уже сама по себе является вызовом (см., например, мультисенсорные иллюзии). Когда получает воздействия от большинства органов чувств сразу, а изображение поступает с некоторой дополнительной задержкой, то это усложняет ситуацию ещё больше.
Нервная система может в некоторой степени адаптироваться (pdf-файл) к постоянной задержке зрительной обратной связи (хотя и не идеально), но любые нерегулярности длительности задержки (т.н. дрожание (джиттер)) создают дополнительные проблемы из-за свойственной им непредсказуемости.
Есть несколько показательных примеров из других областей, где задержка сигналов обратной связи может вызывать худшие последствия, чем её полное отсутствие, вплоть до ситуации, когда исходная деятельность становится вообще невозможной: если играть на MIDI-клавиатуре через компьютер, то задержки звука на 20-30 мс достаточно, чтобы нарушить ваши действия (одна статья (pdf-файл) утверждает, что имеет значение задержка звука даже прим. на 1 мс); другим хорошим примером является т.н. SpeechJammer (pdf-файл) («истребитель болтовни»), который использует задержку звука обратной связи на прим. 200 мс, временно нарушая способность человека говорить.
1.5. Эффекты
Соберём вместе ключевые моменты:
• Печатание (ввод на клавиатуре) является сложным полуавтоматическим процессом, требующим годы на освоение.
• В принципе на процесс печатания можно влиять миллисекундными задержками в зрительной обратной связи.
• Совсем необязательно воспринимать сознанием наличие задержки, чтобы, тем не менее, она отрицательно влияла на вас.
• Люди сильно различаются по восприимчивости и толерантности к задержке.
Но как конкретно задержка влияет на процесс печатания (ввода на клавиатуре)? Здесь имеется несколько возможных эффектов:
• Печатание замедляется.
• Количество ошибок и их правок возрастает.
• Глаза устают больше (поскольку система зрения перегружена).
• Мышцы устают сильнее (поскольку управление движениями становится менее определённым).
• Процесс требует более осознанного внимания.
Точное воздействие задержки зависит от многих факторов, таких как конкретное распределение задержки, используемое аппаратное обеспечение (клавиатура, монитор), содержание редактора (текст или код), основной вид деятельности (вставка/редактирование), метод печатания (обычный/слепая печать), специфика вашего зрения и вашей моторики, персональные предпочтения и т.п.
Само собой разумеется, возможное влияние задержки вряд ли приятно. Хорошая новость состоит в том, что это работает в обоих направлениях, т.е., уменьшая зрительную задержку, мы можем, в общем случае, улучшить много аспектов (здесь речь идёт не только о скорости печатания самой по себе)
Полученные результаты, как правило, согласуются с имеющимися данными исследований. Если есть желание ознакомиться с этим предметом глубже, то можно посмотреть некоторые книги и научные статьи, содержащие данные о влиянии задержки и о роли зрительной обратной связи на процесс печатания, например:
• Когнитивные аспекты профессиональной машинописи
• Роль зрительной обратной связи с экрана и рук в профессиональной машинописи (pdf-файл)
В частности, стоит процитировать следующее (источник):
Задержка зрительной обратной связи на дисплее компьютера имеет важное воздействие на поведение оператора и на его удовлетворённость работой.
Давайте теперь рассмотрим сторону машины, чтобы выяснить, как мы можем улучшить ситуацию с задержкой.
2. Сторона машины
Что происходит между моментом нажатия на клавишу и моментом появления символа на экране? Оказывается, очень много разного, и всё требует времени. Можно ли просто купить топовый компьютер, чтобы обеспечить себе спокойное печатание? Это поможет, но лишь в какой-то степени, поскольку многие части этого процесса не зависят от центрального и/или графического процессоров. Прими обе таблетки, и я покажу тебе, как глубоко уходит кроличья нора (потому что даже то, что последует, является лишь частью всей правды).
Задержка печатания может быть разделена на следующие компоненты:
• Входная задержка (клавиатура)
• Задержка обработки (программное обеспечение)
• Выходная задержка (монитор)
Рассмотрим внимательнее каждую компоненту.
2.1. Входная задержка
Сначала разберёмся, как обычная неигровая USB-клавиатура обрабатывает наш ввод. Такие клавиатуры используются наиболее широко сейчас как на настольных компьютерах, так и на лэптопах.
Сканирование клавиатуры
Обычная клавиатура содержит более 100 клавиш, что довольно много. Чтобы минимизировать количество проводов и входов управляющего процессора, клавишные переключатели обычно соединены в матричной схеме, т.е. «строки» и «столбцы» проводов пересекаются. Благодаря этому количество проводов и входов можно уменьшить с «x * y» до «x + y» (например, со 121 до 22). Следствием такого подхода является то, что управляющий процессор не может считывать состояние всех клавиш одновременно — он должен периодически сканировать их с постоянной частотой, что ведёт к некоторой задержке. Типичная частота сканирования матрицы составляет 1 000 Гц, поэтому максимальная задержка, связанная со сканированием, равна 1 мс (средняя — 0,5 мс).
Дребезг контактов
Независимо от типа клавиатуры клавишные переключатели механически несовершенны и подвержены дребезгу контактов — вместо «чистого» срабатывания переключатель быстро переходит из состояния «вкл.» в состояние «выкл.» и обратно несколько раз, прежде чем остановится. Длительность дребезга зависит от технологии переключения; например, для устройств Cherry MX, как заявлено, она составляет менее 5 мс. Хотя точное распределение вероятности неизвестно, но базируясь на соответствующих эмпирических данных, можно принять длительность дребезга около 1,5 мс.
Устранение дребезга контактов
Поскольку частота опроса довольно велика и из-за этого дребезг может быть интерпретирован как несколько нажатий клавиши, процессор управления клавиатурой выполняет т.н. устранение дребезга контактов, усредняя сигналы на интервале времени, достаточном для получения надёжного результата. Такая фильтрация вводит дополнительную задержку, зависящую от прошивки микроконтроллера. Поскольку изготовители, в общем случае, не сообщают характеристики их микропрограмм, то рассмотрим типичный алгоритм устранения дребезга и примем, что фильтрация добавляет прим. 7 мс задержки; т.о. максимальное «время устранения дребезга» составляет прим. 12 мс, а среднее прим. 8,5 мс.
USB-опрос
Поскольку USB является шиной, управляемой главным компьютером, то клавиатура должна ждать запрос от этого компьютера, чтобы послать данные о зарегистрированном нажатии клавиши (процессор управления клавиатурой располагает собранные события в выходном буфере). Хотя USB-устройства запрашивают требуемую частоту опроса при инициализации (до 1 000 Гц), операционные системы обычно используют 125 Гц, как для низко-, так и для полноскоростных (USB1.x) устройств; поэтому максимальная задержка, связанная с опросом, составляет 8 мс (средняя — 4 мс). Следует помнить, что часто можно повысить частоту опроса вручную.
USB-преобразование
Некоторое время требуется также на преобразование данных. Как для низко-, так и для полноскоростных устройств наименьшая длительность преобразования составляет 1 мс. У высокоскоростных устройств (USB2) это время много меньше — прим. 0,001 мс (кстати, имеется прекрасная статья о пригодности USB для систем реального времени (pdf-файл)). Чтобы минимизировать время преобразования данных, рекомендуется не подключать широкополосные USB-устройства (такие как, например, накопители, звуковые карты, веб-камеры) к тому же USB-контроллеру / хабу, к которому подсоединена ваша клавиатура.
Итак, соберём значения задержки для типичной клавиатуры:
Эти результаты, в общем, соответствуют некоторым экспериментальным результатам по измерению запаздывания, вызываемого клавиатурой.
Можно ли сделать лучше? Конечно, проще простого! Используйте профессиональную клавиатуру:
• переключатели с малым временем дребезга (некоторые даже оптические)
• высокая частота сканирования матрицы
• адаптивный алгоритм устранения дребезга
• настраиваемое микропрограммное обеспечение
• USB2 для быстрого опроса и малой задержки преобразования
Всё это может значительно уменьшить как максимальное, так и среднее значение задержки клавиатуры. Например, когда я приобрёл клавиатуру Kinesis Advantage, я сразу почувствовал отличие от моей предыдущей «обычной» клавиатуры.
Игровые клавиатуры идут даже дальше — если вы сторонник бескомпромиссного решения, то стоит рассмотреть что-то вроде технологии Cherry’s RealKey, при которой считывание клавиш идёт через аналоговые входы (а не цифровые); задержка получается почти нулевая.
2.2. Задержка обработки
Задержкой обработки называется задержка между получением входного сигнала с клавиатуры и генерацией изображения введённого символа в видеокадре. Проще говоря, это задержка внутри самого компьютера.
Следует помнить, что задержка обработки не определяется только производительностью — теоретически можно иметь систему, выдающую 300 FPS, с «запаздыванием» 5 секунд после ввода. В частности, пакетирование и буферизация часто являются попыткой достичь более высоких рабочих характеристик за счёт задержки.
В то время как концептуально есть много различных источников задержки обработки, на практике они настолько тесно связаны с применением редактора, что все части обычно измеряют вместе (экспериментальные данные см. в следующей главе).
Операционная система
После того как USB-хост («USB-порт» компьютера) получает данные с клавиатуры, он инициирует аппаратное прерывание так, чтобы программный драйвер в операционной системе мог прочитать полученные данные через интерфейс хост-контроллера (обычно через PCI или PCIe). Затем эти данные обрабатывает подсистема человеко-машинного интерфейса (HID) в ОС, что в итоге приводит к помещению события «клавиша нажата» (типа WM_KEYDOWN) в очередь сообщений операционной системы. После этого событие отправляется циклом событий в окно активного приложения.
Все эти действия требуют некоторого времени, но оно пренебрежимо мало для нашей цели (печатание на клавиатуре). Что здесь важно, так это то, что основные операционные системы (а именно — Windows, Mac и ОС на базе Linux) не являются системами реального времени, поэтому гарантия на значение задержки отсутствует. Как аппаратные процессы (сетевой ввод/вывод, ввод/вывод сохранения и т.п.), так и многозадачность программного обеспечения могут увеличить время обработки непредсказуемо (и неограниченно).
Кстати, поскольку приложения графического пользовательского интерфейса могут накладывать жёсткие ограничения на системную задержку, было много успешных попыток оптимизировать планирование ядра Linux специально для случая «настольного» использования (в частности, через систему динамической оптимизации «ulatencyd»).
Для простоты предположим, что наш компьютер не имеет значительной загрузки при вводе с клавиатуры; тогда задержки такого рода будут менее 1 мс.
Виртуальная машина
Если текстовый редактор / IDE работает поверх виртуальной машины процесса (как JVM у Java или CLR у .NET Framework), то дополнительные задержки могут возникнуть потому, что их среда выполнения также не является системой реального времени (за исключением специальных реализаций, как, например, Real time Java).
Производительность сама по себе обычно не создаёт проблемы, но, когда включается JIT-компилятор или сборщик мусора, можно ожидать некоторое «запаздывание». Движки JavaScript и интерпретатор Emacs Lisp также порождают такой тип задержек.
Основные виртуальные машины значительно усовершенствовались за многие годы, тем не менее, некоторый предварительный «прогрев» мог бы быть, всё же, полезным, чтобы гарантировать стабильную задержку.
Редактор
Эта часть — самая значимая. Используемый редактор может дать основной вклад в задержку печатания. В отличие от задержек, создаваемых аппаратурой, максимальная задержка в редакторе практически не ограничена (можно легко наткнуться на 1-2 секунды).
Поскольку редактор завязан, в основном, на центральный процессор, можно уменьшить задержку редактора, применяя более мощную машину (помогает также хороший графический процессор). Но надежда только на мощность не совсем оправдана — она часто уходит не туда, где она, действительно, нужно больше всего (например, когда вы запускаете сервер разработки или обработку каких-то данных в фоновом режиме). Также имейте в виду, что даже первоклассный ноутбук может быть намного более вялым в энергосберегающем режиме (на аккумуляторе), поэтому такой подход эффективен только частично. Кроме того, он довольно дорогой, как известно.
Есть путь получше — в принципе, нам не нужен суперкомпьютер для спокойного печатания — всё, что мы должны сделать, так это реализовать использование редактора, памятуя о поставленной цели. Печатание в редакторе является сравнительно простым процессом, поэтому даже компьютеры на 286 процессоре обеспечивали довольно быстрый ввод. Вполне возможно достигнуть близкую к нулю задержку печатания даже в сложном современном IDE, что является именно тем, на что нацелен режим печатания с нулевой задержкой в IntelliJ IDEA. Технические подробности см. в моей статье об отрисовке с малой задержкой в AWT и Swing (несмотря на то, что рассматривается платформа Java, ключевые идеи могут быть распространены на большинство современных операционных систем и фреймворков для построения графических пользовательских интерфейсов).
Редакторы/IDE сильно различаются по задержке печатания. Следующая глава содержит большое количество эмпирической информации по теме.
Конвейер рендеринга
Центральный и графический процессор работают параллельно и взаимодействуют через буфер команд, дополненный буфером видеодрайвера. Большинство команд рендеринга являются асинхронными. Поэтому они имеют полное право не запускаться сразу, как только отработает метод отрисовки. Команды отрисовки накапливаются в буфере видеодрайвера, затем пакетируются и направляются в буфер команд графического процессора (делается попытка получить более высокую частоту кадров за счёт задержки). Результирующая задержка, в зависимости от комбинации аппаратного обеспечения / операционной системы / программного интерфейса приложения / видеодрайвера — может меняться от незначительной до весьма существенной.
Типичное приложение настольного компьютера работает поверх фреймворков для построения графических пользовательских интерфейсов, поэтому оно изолировано от находящегося ниже конвейера рендеринга и, таким образом, от синхронизации визуализации (рендеринга). Обычно это приемлемо, т.к. многие приложения для настольных систем нечувствительны к задержке. Однако некоторые действия чрезвычайно чувствительны к ней (как, например, печатание в IDE), из-за чего редакторы могут явным образом “протолкнуть” команды в буфере и принудительно отрендерить кадр, чтобы уменьшить задержку. Как пример, см. работу синхронизации в OpenGL. Можно также посмотреть демонстрационный материал о ”проталкивании” конвейера.
Двойная буферизация
Чтобы не показывать частично прорисованный кадр и представить изображение на экране сразу целиком, многие приложения обращаются к т.н. двойной буферизации — изображение первоначально подготавливается во внеэкранном «вторичном буфере», а когда все графические операции завершены, обновлённая область изображения передаётся в кадровый буфер путём побитового копирования или путём переключения страницы. Многие фреймворки (например, Swing) выполняют двойную буферизацию по умолчанию.
Излишне говорить, что этот дополнительный шаг приводит к дополнительной задержке. В документации Java сказано: «Если вашей метрикой производительности является просто скорость, с которой происходит двойная буферизация или переключение страниц по сравнению с прямым рендерингом, то вы можете быть разочарованы. Может оказаться, что значения у прямого рендеринга будут намного превосходить таковые у двойной буферизации, а эти, в свою очередь, будут много выше чем у переключения страниц.»
Иногда двойная буферизация абсолютно необходима, в других случаях это фактически не требуется; поэтому редакторы должны использовать двойную буферизацию осмотрительно, чтобы не допустить чрезмерной зрительной задержки. Дальнейшую информацию см. в демонстрационном материале по издержкам буферизации.
Менеджер окон
Современные приложения редко работают в полноэкранном режиме; большинство сред рабочего стола показывает каждую программу в отдельном окне. Эту задачу выполняют т.н. менеджеры окон, которые могут быть разделены на несколько классов в зависимости от того, как происходит прорисовка и обновление окон.
стековые оконные менеджеры организуют изображение перекрывающихся окон так, что сначала выполняется прорисовка окон, расположенных сзади. В то время как у этого подхода есть некоторые недостатки (необходимость явного восстановления содержимого окна), он не вносит дополнительные задержки, потому что приложения рисуют непосредственно в кадровом буфере. Примеры стековых оконных менеджеров: Classic theme в Windows, Openbox в Linux.
Композитные менеджеры окон используют вместо кадрового буфера выделенный внеэкранный буфер для каждого окна и затем выводят на экран все окна вместе, когда (и как) они считают целесообразным. Это разделение неизбежно приводит к некоторому увеличению задержки. Примеры компонующих менеджеров: Aero в Windows, Compiz в Linux.
Соответствующие эмпирические данные приведены в следующей главе.
Вертикальная синхронизация
Вертикальная синхронизация или V-Sync является методом предотвращения разрыва изображения на экране, т.е. такого состояния, когда дисплей показывает информацию из нескольких кадров в одном изображении экрана. Возникающие искажения наиболее заметны на горизонтально двигающихся объектах с резкими вертикальными краями (т.е. не во время печатания).
V-Sync сводится к ожиданию нового кадра в сгенерированном видеосигнале перед передачей содержимого вторичного буфера в кадровый буфер (таким образом, V-Sync подразумевает двойную буферизацию). Поэтому при включённой вертикальной синхронизации может быть дополнительная задержка перед обновлением кадрового буфера. Максимальная задержка составляет примерно 17 мс, средняя — около 8 мс (для частоты обновления 60 Гц). Интересно, что эта задержка связана с обновлением экрана, из-за чего её среднее полное значение возрастает только примерно на 4 мс, поскольку часть этой задержки является неустранимой (зависит от вертикальной позиции символа). Максимальное увеличение полной задержки достигает, всё же, примерно 17 мс.
Среды рабочего стола обычно не позволяют явно выбирать, включать или нет V-Sync. V-Sync в Windows разрешена в Aero, но запрещена в Classic theme. V-Sync в Linux, кажется, выключена, как в композитных, так и в стековых оконных менеджерах.
В некотором смысле V-Sync вынуждает графический процессор адаптироваться, чтобы контролировать частоту обновления, что является наследством эры электронно-лучевых трубок. В настоящее время имеются намного более предпочтительные решения (см. ниже).
Рассмотрим значения задержки для типичного компьютера (принимаем, что значительные нагрузки на ввод/вывод и вычислитель отсутствуют и что используется стековый менеджер окон без V-Sync):
Эти задержки намного менее предсказуемы, чем задержки, вызванные аппаратными средствами, и они очень чувствительны к конфигурации компьютера. В принципе полная задержка обработки может быть как 0-1 мс, так и 10 с. Вот почему теоретических размышлений здесь недостаточно и нужны некоторые точные цифры — см. в следующей главе обширные эмпирические данные.
Как можно улучшить ситуацию с задержкой обработки? Здесь есть несколько путей:
• Редактор/IDE с малой задержкой
• Мощное аппаратное обеспечение компьютера (центральный и графический процессоры)
• Стековый менеджер окон (Classic Windows theme, Openbox и т.п.).
• Отсутствие вертикальной синхронизации
Очевидно, что редактор имеет самое большое значение.
2.3. Выходная задержка
Рассмотрим, как типичный неигровой жидкокристаллический монитор показывает сгенерированное изображение.
Обновление экрана
Изображение экрана компьютера хранится в кадровом буфере в памяти видеокарты (или в разделяемой видеопамяти). Монитор не имеет прямого доступа к кадровому буферу; вместо этого видеоконтроллер генерирует видеосигнал, передаваемый через видеоинтерфейс (такой как VGA, DVI, HDMI, DisplayPort и т.д.), благодаря чему монитор может непрерывно обновлять свой внутренний буфер изображения. Эта передача происходит с фиксированной частотой, называемой частотой обновления, которая для обычных ЖК-мониторов равна 60 Гц. Поэтому можно ожидать, что максимальная задержка, связанная с обновлением, равна примерно 17 мс, а средняя — примерно 8 мс (поскольку нам требуется показать только новый введённый символ, то можно не учитывать время, требуемое для передачи полного кадра).
Запаздывание дисплея
В отличие от ЭЛТ-монитора, который должен показать входящее изображение немедленно (потому что его единственная «память» — послесвечение люминофора), ЖК-монитор имеет свой собственный буфер для хранения изображения. В принципе это делает возможным задержать показ входящего изображения, чтобы изменить размеры, выполнить деинтерлейсинг или как-то «улучшить» его (или просто получить полный кадр, прежде чем обновить пиксели). Возникающая задержка известна как запаздывание дисплея (или «запаздывание ввода монитора»). Это явление получило широкую огласку в последнее время, но оно всё ещё является довольно спорной темой. Измерения запаздывания дисплея часто являются неправильными, т.к. трудно отделить это запаздывание от времени отклика пикселя (см. прекрасный отчёт Prad по запаздыванию ввода, чтобы понять, как делать это правильно). Хотя в худшем случае задержка может быть 2-3 кадра (т.е. до 50 мс при частоте обновления 60 Гц), запаздывание ввода представлено, в основном, в телевидении высокой чёткости, а не в мониторах компьютеров; поэтому можно принять, что эта задержка близка к нулю для типичных мониторов. Тем не менее, хорошей идеей будет выключить все «корректоры изображения» на вашем мониторе (как ни странно, и овердрайв тоже).
Отклик пикселя
Пиксели ЖК-дисплея не могут реагировать на изменения управляющего напряжения немедленно. Интервал времени, требуемый для изменения пикселя на дисплее, называется временем отклика пикселя. Это время зависит, в основном, от технологии ЖК-матрицы (TN, IPS, VA и т.д.). ЖК-мониторы прошли длинный путь, снижая время отклика пикселя, и современные TN-мониторы (используемые наиболее широко в настоящее время) имеют среднее время отклика всего лишь около 4 мс.
Итак, соберём значения задержки для типичного компьютерного монитора:
Можно ли уменьшить выходную задержку? Здесь имеется несколько надёжных методов:
• Игровой монитор, обеспечивающий малое запаздывание дисплея и более быстрый отклик пикселя.
• Монитор с частотой обновления 144 Гц (задержка, связанная с обновлением, равна 3,5 мс).
• Комбинация видеокарты и монитора, которая поддерживает Adaptive-Sync, FreeSync или G-Sync с динамической частотой обновления (до 240 Гц) и синхронные обновления.
Все эти меры могут снизить полную выходную задержку до прим. 1-2 мс.
2.4. Полная задержка
Просуммируем средние задержки во всех компонентах задержки печатания:
Типичный комплект состоит из обычной неигровой клавиатуры и обычного ЖК-монитора. Идеальная конфигурация предполагает клавиатуру и монитор (игровой), имеющие малую задержку.
Входная и выходная компоненты задержки строго определяются периодическими аппаратными процессами, которые могут быть оценены с высокой точностью. Эти задержки не зависят от производительности центрального и графического процессоров и имеют предсказуемые верхние границы. Типичная средняя задержка клавиатуры и монитора вместе составляет около 26 мс, что само по себе немного, но если её добавить к задержке обработки, то задержка редактора будет более заметной. Даже задержка ввода/вывода сама по себе уже превышает порог человеческого восприятия.
Задержка обработки в отличие от задержек ввода/вывода определяется, в первую очередь, вычислениями центрального и графического процессоров, поэтому она зависит от аппаратного обеспечения и имеет практически неограниченное максимальное значение. Невозможно предсказать задержку обработки; требуется выполнить надлежащие сравнительные тесты, чтобы получить эти данные. Теоретически идеальная задержка обработки может быть близка к 0-1 мс.
В то время как каждая часть рассматриваемой цепочки имеет значение, редактор является наиболее слабым звеном, вносящим основной вклад в задержку печатания.
3. Сравнительные тесты редакторов
Чтобы экспериментировать с измерением задержки обработки, я подготовил «Typometer» — инструмент для определения и анализа зрительной задержки текстовых редакторов (источники).
Typometer генерирует входные события ОС и делает снимок изображения экрана, чтобы измерить задержку между нажатием клавиши и соответствующим обновлением экрана. Таким образом, измерение охватывает все составляющие задержки обработки (т.е. очередь ОС, виртуальная машина, поток графического процессора, буферизация, менеджер окна и возможная вертикальная синхронизация). Такой подход является правильным, потому что все компоненты, по сути, переплетены с редактором и, в принципе, редактор влияет на них.
3.1. Конфигурация
Здесь описана конфигурация аппаратного и программного обеспечения, использованная для тестирования:
Аппаратное обеспечение:
• ЦПУ: Intel Core i5 3427U, 1,8/2,8 ГГц, кэш 3Mб
• Графика: Intel HD 4000 (драйвер v10.18.10.3958)
• Память: 4 Гб DDR3
• Дисплей: 1920 x 1080, 32 бита, 59,94 Гц
Программное обеспечение:
• Microsoft Windows 7 HP x64 SP1 6.1.7601
• Lubuntu Linux 15.10 Desktop amd64
• VirtualBox 5.0.10 на Windows (установки по умолчанию, полноэкранный режим)
Редакторы:
• Atom 1.1
• Eclipse 4.5.1
• Emacs 24.5.1
• Gedit 3.10.4
• GVim 7.4.712
• IntelliJ Idea CE 15.0
• Netbeans 8.1
• Sublime Text 3083
Обратите внимание, что, поскольку сравнительные тесты выполняются на одних и тех же аппаратных платформах и на одной и той же версии каждого редактора, то результаты можно прямо сравнивать. Результаты могут изменяться в зависимости от конфигурации, поэтому для сравнительного тестирования был использован довольно типичный комплект (не очень медленный, но и не очень мощный); это делает результаты более репрезентативными.
Были выбраны только те редакторы, которые обеспечивают, как минимум, подсветку синтаксиса. Несомненно, Notepad (Блокнот) — самый быстро реагирующий редактор, но было бы просто несправедливо сравнивать его с любым практически полезным редактором.
Дополнительно были исключены случаи работы редактора в терминале, поскольку терминал может сам существенно влиять на задержку печатания. Кстати, современные ОС больше не поддерживают настоящий текстовый режим — как консоль Windows, так и виртуальная консоль Linux (через Alt+Fn) моделируются поверх графического кадрового буфера.
Анализ был выполнен в R. Графики были представлены при помощи ggplot2.
3.2. Методология
Все редакторы/IDE работали с настройками по умолчанию, окна приложений были максимизированы.
Редактор работал либо с пустым текстовым файлом, либо с XML-файлом (точнее, с Maven-схемой). XML был выбран потому, что он подсвечивается во всех редакторах и не зависит от других файлов проекта.
Typometer использовал следующие параметры:
• Количество символов: 200
• Задержка: 150 мс
• Доступ: нативный
• Режим: синхронный
Задержка 150 мс была выбрана потому, что она представляет собой средний временной интервал между нажатиями клавиш при моём собственном довольно быстром печатании (минимальный интервал равен 40 мс). Точное значение не играет большой роли, т.к. Typometer в синхронном режиме ждёт, когда появится символ, прежде чем сделать паузу и напечатать следующий.
Был использован классический оконный менеджер в Windows, поскольку, как было сказано выше, композитинг, осуществляемый в Aero, увеличивает задержку рендеринга и принудительно включает вертикальную синхронизацию (тесты показали, что Aero theme, действительно, делает все редакторы менее восприимчивыми). Здесь дано сравнение тестов GVim (один из самых быстрых редакторов вообще) в Classic theme и в Aero (пунктирные линии на 16,68 и 33,37 мс):
Влияние Windows Aero на задержку прорисовки (GVim)
Можно видеть, что Aero вносит, как минимум, одну кадровую задержку (прим. 16,7 мс для частоты обновления 60 Гц) и ведёт к дискретизации по времени. Это скрывает внутреннюю производительность редактора и искажает процесс сравнительного тестирования. Как я указывал ранее, задержки видеосигнала, создаваемые вертикальной синхронизацией, немного меньше задержек в кадровом буфере, но средняя разница составляет лишь 4 мс, а максимальная добавляемая задержка равна, всё же, 17 мс (для 60 Гц). Поскольку эффект довольно существенный, люди часто обнаруживают добавленную задержку «невооружённым глазом» в тестах на время реакции человека.
График также демонстрирует, что Typometer имеет очень хорошую точность измерения задержки — нижние значения находятся так близко к теоретическому 16,68335, что это выглядит почти как результат математического расчёта.
Как для Linux, предпочтение было отдано Lubuntu вместо Ubuntu по той же причине — Compiz даёт дополнительную задержку в прорисовку приложения. Здесь представлен график (с медианными линиями):
Влияние Linux Compiz на задержку прорисовки (GVim)
Средняя внесённая задержка составляет прим. 8 мс, что лучше значения у Aero; здесь также отсутствует дискретизация, вызываемая синхронизацией (но здесь наблюдается рост джиттера). Поскольку V-Sync не используется, то задержки видеосигнала находятся на уровне задержек в кадровом буфере. Предпочтительнее использовать стековый менеджер окон (типа Openbox), чтобы получить более высокую точность измерения.
Учитывая, что измеренные задержки самых быстрых приложений, таких как Notepad, ниже 1 мс и стабильные, кажется оправданным предположить, что измерительный инструмент обеспечивает достаточную точность и воспроизводимость. Поскольку связь между кадровым буфером и выходным видеосигналом детерминированная, результаты можно рассматривать как репрезентативные.
Несмотря на богатое разнообразие наблюдаемых зависимостей, можно выделить следующие типичные временные ряды:
Типичные временные ряды задержки редактора
Простые редакторы демонстрируют очень стабильные значения задержки, хотя средняя величина может быть сравнительно большой.
Сложные редакторы (и редакторы, работающие поверх виртуальной машины / интерпретатора) в дополнение к более высокой средней задержке часто имеют тенденцию к более высокой изменчивости задержки (джиттер).
Распространено также промежуточное поведение, когда интервалы стабильного значения задержки периодически прерываются случайными выбросами. Иногда задержка проявляет тенденцию, показывающую линейную зависимость от алгоритмов редактора по горизонтальному позиционированию символов.
3.3. Windows
Как введение в методику анализа задержки, рекомендую просмотреть большое обсуждение, как не надо измерять задержку, которое объясняет, почему средние значения лучше медианных в качестве меры задержки и почему максимальные значения очень важны.
Текстовый файл
Посмотрим итоговую таблицу (отсортировано по среднему значению задержки). SD означает здесь среднеквадратическое отклонение, используемое как мера джиттера. Учтите, что здесь представлена «идеальная» ситуация — простой пустой файл без выделения. Любая другая конфигурация показала бы более высокие задержки по определению.
Задержка редактора в Windows (текстовый файл):
Итоговая таблица даёт нам возможность лишь примерно оценить распределение задержки, поэтому полезно дополнить её соответствующей более подробной графикой. Традиционные гистограммы не очень удобны для сравнения нескольких наборов данных. Диаграммы размаха (“ящики с усами”) являются слишком грубыми. Скрипичные диаграммы лучше, но они выглядят довольно странно для людей, не занимающихся профессионально статистикой.
Есть более удобный способ, который также и выглядит лучше, — можно графически изобразить значения на горизонтальной оси с некоторым добавленным случайным вертикальным сдвигом, чтобы показать распределение (имеется дополнительная информация о таком подходе). Результирующая диаграмма является простой и описательной и позволяет сравнивать различные наборы данных:
Задержка редактора в Windows (текстовый файл)
Очевидно, редакторы не созданы равными (по крайней мере, по задержке).
Во-первых, средняя задержка различается значительно — более простые редакторы имеют тенденцию к более низкой задержке. Победителем является GVim, но и IDEA со включенным режимом нулевой задержки находится очень близко к GVim. Все редакторы на базе JVM (в т.ч. IDEA в режиме по умолчанию) находятся внизу, что вполне предсказуемо, уступая только Atom, т.к. работа Chrome оказалась ещё более вялой.
Другим заметным отличием является джиттер — «лёгкие» редакторы демонстрируют очень стабильную задержку, тогда как сложные, наоборот, имеют намного более широкий разброс значений. IDEA в режиме по умолчанию показывает самый большой разброс задержки с высоким максимальным значением.
Гистограмма ниже демонстрирует подробное воздействие режима нулевой задержки в IntelliJ IDEA:
Влияние режима нулевой задержки в Windows (текстовый файл)
Режим нулевой задержки сказывается положительно, снижая среднюю задержку и устраняя джиттер (но не полностью).
XML-файл
Ясно, что предыдущий набор является слишком «искусственным»; в конце концов, для редактирования пустого файла без какой-либо подсветки синтаксиса можно взять просто Notepad. Для чего-то более серьёзного используют другой редактор. Выполним ввод в сравнительно большом XML-файле, чтобы увидеть, как изменятся значения:
Влияние типа содержания на задержку редактора (Windows)
Ух ты! Различие довольно заметное и одновременно необычное. Некоторые редакторы — GVim и IDEA в режиме нулевой задержки — ну, просто, «крутые парни», им «по барабану». Однако у большинства редакторов задержка равномерно возросла. Средняя задержка в IDEA слегка уменьшилась (что несколько странно), но максимальная — увеличилась. Наиболее сильное изменение произошло у Emacs, задержка которого просто взлетела в небо.
Энергосбережение
Теперь отсоединимся от сети электропитания и будем работать от аккумуляторов в режиме энергосбережения.
Задержка редактора в Windows (XML-файл, энергосбережение):
Рассмотрим подробнее, как это повлияло на задержки:
Влияние режима энергосбережения на задержку редактора (Windows, XML-файл)
На большинстве редакторов это заметно не сказалось, но есть пара примечательных исключений: IDEA и Netbeans. У IDEA максимальная задержка взлетела к 240 мс, что, вполне очевидно, выше порога «ощутимости».
Здесь показано, как режим нулевой задержки сказывается в данных условиях:
Влияние режима нулевой задержки в Windows (XML-файл, энергосбережение)
И снова, хотя он не устраняет джиттер полностью, воздействие значительное.
3.4. Linux
Продолжим наши наблюдения в Linux, пропустив для простоты синтетический тест с пустым файлом.
Задержка редактора в Linux (XML-файл):
Дополнительная диаграмма с подробным распределением задержки:
Задержка редактора в Linux (XML-файл)
Сравнение с предыдущими результатами в Windows:
Влияние ОС на задержку редактора (XML-файл)
Общей особенностью является то, что джиттер в Linux заметно выше для большинства редакторов (за исключением режима нулевой задержки в IDEA, где джиттер фактически уменьшился).
Emacs и Atom выигрывают в Linux — их средняя задержка здесь заметно меньше.
У GVim, Sublime Text, Eclipse и IDEA (в режиме по умолчанию), наоборот, задержка в Linux намного возросла. Наиболее сильное воздействие испытала IDEA — максимальная задержка достигла 200 мс даже в режиме обычного питания. Время реакции Eclipse также сильно пострадало.
Печатание в IDEA в режиме нулевой задержки является, конечно, победителем (здесь IDEA обошёл даже GVim).
Влияние режима нулевой задержки в Linux (XML-файл)
Режим нулевой задержки в Linux демонстрирует низкую и исключительно стабильную задержку.
3.5. VirtualBox
Теперь предположим, например, что мы используем Windows, прежде всего, для игр, а работаем на виртуальной машине Linux (действительно, почему бы и нет?). Как изменятся задержки редактора в такой ситуации использования? Посмотрим.
Задержка редактора в Linux (VirtualBox, XML-файл):
Здесь дано сравнение с предыдущими «естественными» результатами:
Влияние виртуализации на задержку редактора (Linux, XML-файл)
Помимо дискретизации задержки (вызываемой либо вертикальной синхронизацией, либо другим видом дискретной синхронизации буфера) мы можем видеть постоянный рост задержки для всех редакторов. Распределения сильно не изменяются, что легко объяснимо (базовые алгоритмы сохраняются при визуализации). Максимальная задержка в IDEA выросла до 350 мс.
Энергосбережение
Чтобы получить полную картину, переключимся на аккумуляторы. Режим энергосбережения вместе с VirtualBox является, вероятно, самой напряжённой комбинацией для задержки редактора.
Задержка редактора в Linux (VirtualBox, XML-файл, энергосбережение):
Н-да, такие задержки просто нелепы! Максимальная задержка теперь превышает полсекунды!!!
Для наглядности давайте сравним эти данные с результатами при идеальных условиях:
Влияние конфигурации на задержку редактора
Совершенно очевидно, что конфигурация играет важную роль в результирующей задержке редактора. Однако редакторы реагируют по разному — работа некоторых может быть серьёзно ухудшена, тогда как на других это сказывается несильно.
Наилучшую стойкость продемонстрировал IntelliJ IDEA с включенным режимом нулевой задержки. Посмотрим, как это выглядит в наиболее трудной ситуации:
Влияние режима нулевой задержки в VirtualBox (Linux, XML-файл, энергосбережение)
Интересно, что в режиме нулевой задержки IntelliJ IDEA превосходит все другие редакторы (и, кстати, консольные редакторы тоже).
4. Выводы
Конечно, то, что вы печатаете, намного важнее того, как вы печатаете. Однако зрительная обратная связь с малой задержкой часто может сделать этот процесс более эффективным и более приятным.
• Используйте быстро реагирующий редактор.
• Используйте клавиатуру с малой задержкой.
• Выключите все «улучшатели изображения» на вашем мониторе.
• Включите стековый менеджер окон в вашей ОС.
Печатайте с удовольствием!
5. Ссылки
Смотрите также:
• Typometer — инструмент для измерения и анализа зрительной задержки в редакторах текста/кода.
• Процесс отрисовки с малой задержкой в AWT и Swing — детальный анализ источников задержки в архитектурах AWT и Swing, методов значительного снижения задержки прорисовки.
Автор: LukinB
