Время отклика
Время отклика в компьютерных системах – это максимально допустимый размер таймаута между действием пользователя и реакцией компьютерной системы. Первоначально под временем оклика понималась величина максимального промежутка времени между актами взаимодействия оператора или внешнего оборудования с т.н. системой реального времени. Подобные системы обязаны были в срок отреагировать на любые управляющие сигналы, если этого не происходило, то такая система исключалась из разряда систем реального времени.
Эволюция понятия время отклика.
В общем случае термин «время отклика» может относиться к любой компоненте компьютера, сетевому взаимодействию и к произвольному программному обеспечению.
При сетевом взаимодействии под временем отклика понимается время, за которое один элемент сегмента сети («отправитель») получает подтверждение прихода пакетов данных от другого элемента – «получателя». Ими могут быть как компьютеры, так и прочее оборудование, коммутаторы, маршрутизаторы и т.д.
В этом же контексте можно рассматривать время отклика между клиентом, пользующимся услугами базы данных. Здесь существенно максимальное время получения ответа на запрос пользования.
В современных интерактивных системах, клиентом которых обычно выступает браузер, а все программное обеспечение расположено на удаленном сервере, под временем отклика удобно понимать среднее время доступа к тому или иному сервису. Например, к каталогу интернет-магазина или к результату запроса, полученному от поисковой системы сайта.
В различных случаях под временем отклика понимаются, то минимальные, то максимальные, то средние про величине промежутки времени. Это связано с конкретной спецификой и опытный пользователь обязательно уточнит – что имеется в виду конкретно.
Время отклика интерфейса
Скорость работы интерфейса значительно влияет на пользовательский опыт.
Быстрый интерфейс дает ощущение контроля и управляемости. Медленный — раздражает, провоцирует ошибки и повышает вероятность того, что пользователи будут звонить в техподдержку, а не пытаться разобраться самостоятельно.
«Пользователь просто не хочет разбираться в тормозящем интерфейсе — он хочет ответ сходу». Быстрый интерфейс: почему сервис должен летать?
Ответственность дизайнера — следить за скоростью отклика в его продукте:
Что такое «быстро» и «медленно»
Для разных действий в интерфейсе понятия «быстро» и «медленно» отличаются.
Отклик в 100 миллисекунд воспринимается как мгновенный — так элементы интерфейса должны реагировать на наведение, движение мыши или клик.
Задержка в 1 секунду заметна, но не выбивает пользователя из контекста. Нормально, если страница или список загружаются за секунду, но если секунда проходит между кликом и открытием меню, это медленно.
Процессы, которые длятся больше секунды, нужно оптимизировать.
Ощущения «быстро» и «медленно» зависят ещё и от контекста. Если информация или действия от продукта нужны срочно, секунды будут идти дольше, чем обычно. Дизайнер не может влиять на контекст использования, но может его учитывать как обстоятельство пользовательских сценариев.
Как избежать долгого ответа
Скорость работы десктопного приложения зависит только от мощности компьютера. На отзывчивость веб-приложений также влияют быстродействие сервера и качество интернет-соединения.
Чтобы замаскировать неизбежные паузы в работе веб-приложения и сделать его максимально отзывчивым, используйте асинхронные запросы и приемы, описанные в этом гайде.
Мгновенная обратная связь
Выполнение команды пользователя может занимать какое-то время, но обратная связь интерфейса должна быть мгновенной. Так пользователь сразу поймет, что приложение отреагировало на его действие.
Например, выделяйте пункт меню сразу после нажатия на него, а содержание раздела грузите параллельно:
Показывайте раскрывающийся список мгновенно, а данные — после того, как загрузятся:
Если некритичное действие требует изменений на сервере, используйте «оптимистичные» интерфейсы — показывайте, что всё сработало, еще до того, как пришел ответ от сервера. Например, пользователь лайкает пост, приложение мгновенно увеличивает количество лайков на 1 и отправляет запрос на сервер. Иногда что-то может пойти не так и голос не будет учтен, зато в большинстве случаев пользователь получит мгновенную обратную связь.
Предзагрузка
Загружайте сразу только ту часть контента, которая необходима для первого отображения страницы и наиболее вероятных действий пользователя.
Например, предзагружайте следующее изображение в галерее, чтобы не пришлось показывать лоадер, когда пользователь захочет к нему перейти:
В «ленивой подгрузке» всегда держите данные на 1–2 экрана вперед.
Параллельная загрузка
Если на странице есть что-то тяжелое — обязательно выделяйте эти данные в отдельный запрос, чтобы они не задерживали отображение остальной страницы и грузились параллельно.
Например, страница поисковой системы должна быть сверстана так, чтобы строка поиска появилась самой первой:
На странице бронирования Стаффа занятость переговорок формируется очень медленно, но ее загрузка отделена от остальных элементов, и поэтому сама страница загружается моментально:
Фоновые операции
Уводите в фон долгие операции. Например, загрузка файла на сервер не должна блокировать действия пользователя на странице.
Оптимизация файлов
Используйте SVG для всех иконок и небольших иллюстраций. Не используйте шрифт Kontur Iconic в html-верстке, для этого создана специальная SVG-библиотека.
Иллюстрации с большим количеством деталей сохраняйте в SVG и PNG, оптимизируйте, после этого выбирайте файл с меньшим весом.
JPG используйте только для фотографий.
Сжимайте картинки с помощью специальных сервисов — это уменьшает их размер на 50–70 %. Например, используйте сервис Squoosh.
Если картинка весит больше 100 KB, подумайте еще раз, так ли она необходима. Возможно, ее стоит изменить, чтобы уменьшить размер.
Остальные файлы должны сжиматься автоматически: для релиза используйте отдельную конфигурацию вебпака с включенной минификацией.
Кеширование
Кешируйте данные, и загружайте их повторно, только если есть изменения. Это позволяет мгновенно переключаться между загруженными страницами, в том числе делать переход по кнопке «Назад» с сохранением позиции скролла.
Клиентский рендеринг
Если пользователь взаимодействовал с каким-то элементом, отрендерите только его. Например, не перерисовывайте весь список при удалении одного элемента из справочника.
Подготовка данных
Формируйте ответы на «тяжелые» запросы на сервере заранее. Например, Контур.Фокус по расписанию готовит списки связанных организаций. Это позволяет показывать их число рядом с ссылкой и загружать содержимое списка мгновенно.
Что делать, если долгий ответ неизбежен
Индикаторы процесса
Если замаскировать паузу не получилось, нужно показать индикатор процесса, чтобы пользователь понимал — система получила его команду и занята ее выполнением.
Существует несколько терминов близких по смыслу:
У браузеров есть свои индикаторы, но они появляются только когда загружается новая страница. Если отправлен асинхронный запрос внутри страницы — такой процесс браузеры не показывают, поэтому об обратной связи должно позаботиться само приложение.
Индикаторы загрузки в Safari и Chrome
Мы отличаем две ситуации:
Навигация
Когда пользователь переходит между экранами приложения, открывает лайтбоксы, пользуется пейджингом и т.д. могут возникать паузы в загрузке контента. В таком случае яркий анимированный лоадер не нужен, он будет только привлекать внимание к задержке, а не маскировать ее.
Для таких ситуаций мы применяем глобальный лоадер, который располагается вверху экрана. В паре с глобальным лоадером используется минискелетон или полноценный скелетон в том месте страницы, где появится контент:
Исключением являются отдельные тяжелые запросы, выполнение которых, занимает заведомо больше времени. Пример – список переговорок в Стаффе. У такого блока может быть отдельный лоадер, который появляется после рендеринга контента.
Запуск задач
Если пользователь сам запускает продолжительную задачу, также нужно показать лоадер, но есть несколько отличий:
В большинстве таких случаев достаточно спиннера, но иногда стоит потратить время и сделать полноценный прогресс-бар:
Время отклика компьютеров: 1977−2017
У меня гнетущее чувство, что современные компьютеры по ощущениям медленнее, чем те компьютеры, которые я использовал в детстве. Я не доверяю такого рода ощущениям, потому что человеческое восприятие доказало свою ненадёжность в эмпирических исследованиях, так что я взял высокоскоростную камеру и измерил время отклика устройств, которые попали ко мне за последние несколько месяцев. Вот результаты:
| Компьютер | Отклик (мс) | Год | Тактовая частота | Кол-во транзисторов |
|---|---|---|---|---|
| Apple 2e | 30 | 1983 | 1 МГц | 3,5 тыс. |
| TI 99/4A | 40 | 1981 | 3 МГц | 8 тыс. |
| Haswell-E 165 Гц | 50 | 2014 | 3,5 ГГц | 2 млрд |
| Commodore Pet 4016 | 60 | 1977 | 1 МГц | 3,5 тыс. |
| SGI Indy | 60 | 1993 | 0,1 ГГц | 1,2 млн |
| Haswell-E 120 Гц | 60 | 2014 | 3,5 ГГц | 2 млрд |
| ThinkPad 13 ChromeOS | 70 | 2017 | 2,3 ГГц | 1 млрд |
| iMac G4 OS 9 | 70 | 2002 | 0,8 ГГц | 11 млн |
| Haswell-E 60 Гц | 80 | 2014 | 3,5 ГГц | 2 млрд |
| Mac Color Classic | 90 | 1993 | 16 МГц | 273 тыс. |
| PowerSpec G405 Linux 60 Гц | 90 | 2017 | 4,2 ГГц | 2 млрд |
| MacBook Pro 2014 | 100 | 2014 | 2,6 ГГц | 700 млн |
| ThinkPad 13 Linux chroot | 100 | 2017 | 2,3 ГГц | 1 млрд |
| Lenovo X1 Carbon 4G Linux | 110 | 2016 | 2,6 ГГц | 1 млрд |
| iMac G4 OS X | 120 | 2002 | 0,8 ГГц | 11 млн |
| Haswell-E 24 Гц | 140 | 2014 | 3,5 ГГц | 2 млрд |
| Lenovo X1 Carbon 4G Win | 150 | 2016 | 2,6 ГГц | 1 млрд |
| Next Cube | 150 | 1988 | 25 МГц | 1,2 млн |
| PowerSpec G405 Linux | 170 | 2017 | 4,2 ГГц | 2 млрд |
| Пакет вокруг света | 190 | |||
| PowerSpec G405 Win | 200 | 2017 | 4,2 ГГц | 2 млрд |
| Symbolics 3620 | 300 | 1986 | 5 МГц | 390 тыс. |
Это результаты замера отклика между нажатием клавиши и отображением символа в консоли (см. приложение для дополнительной информации). Результаты отсортированы от самых быстрых к самым медленным. При тестировании нескольких ОС на одном компьютере ОС выделена жирным. При тестировании разных частот обновления на одном компьютере они выделены курсивом.
Две последние колонки показывают тактовую частоту и количество транзисторов на процессоре.
Для справки приведено время передачи пакета через весь земной шар по оптоволокну из Нью-Йорка в Нью-Йорк через Токио и Лондон.
Если посмотреть на результаты в целом, то самые быстрые — это древние машины. Более новые компьютеры встречаются во всех частях таблицы. Замысловатые современные игровые конфигурации с необычно высокой частотой обновления экрана почти могут составить конкуренцию машинам конца 70-х и начала 80-х, но «обычные» современные компьютеры не способны конкурировать с компьютерами 30-40-летней давности.
Можно ещё посмотреть на мобильные устройства. В этом случае замерим отклик прокрутки в браузере:
| Устройство | Отклик (мс) | Год |
|---|---|---|
| iPad Pro 10,5″ Pencil | 30 | 2017 |
| iPad Pro 10,5″ | 70 | 2017 |
| iPhone 4S | 70 | 2011 |
| iPhone 6S | 70 | 2015 |
| iPhone 3GS | 70 | 2009 |
| iPhone X | 80 | 2017 |
| iPhone 7 | 80 | 2017 |
| iPhone 6 | 80 | 2014 |
| Gameboy Color | 80 | 1989 |
| iPhone 5 | 90 | 2012 |
| BlackBerry Q10 | 100 | 2013 |
| Huawei Honor 8 | 110 | 2016 |
| Google Pixel 2 XL | 110 | 2017 |
| Galaxy S7 | 120 | 2016 |
| Galaxy Note 3 | 120 | 2016 |
| Nexus 5X | 120 | 2015 |
| OnePlus 3T | 130 | 2016 |
| BlackBerry Key One | 130 | 2017 |
| Moto E (2G) | 140 | 2015 |
| Moto G4 Play | 140 | 2017 |
| Moto G4 Plus | 140 | 2016 |
| Google Pixel | 140 | 2016 |
| Samsung Galaxy Avant | 150 | 2014 |
| Asus Zenfone3 Max | 150 | 2016 |
| Sony Xperia Z5 Compact | 150 | 2015 |
| HTC One M4 | 160 | 2013 |
| Galaxy S4 Mini | 170 | 2013 |
| LG K4 | 180 | 2016 |
| Пакет | 190 | |
| HTC Rezound | 240 | 2011 |
| Palm Pilot 1000 | 490 | 1996 |
| Kindle Paperwhite 3 | 630 | 2015 |
| Kindle 4 | 860 | 2011 |
Как и раньше, результаты отсортированы по времени отклика от самых быстрых к самым медленным.
Если исключить Gameboy Color, который представляет собой иной класс устройств, то все самые быстрые устройства — это телефоны или планшеты Apple. Далее по времени отклика следует BlackBerry Q10. У нас недостаточно данных, чтобы объяснить такую необычно высокую скорость BlackBerry Q10 для не-Apple устройств, но есть правдоподобная догадка, что это объясняется наличием физических кнопок — для них легче реализовать быстрый отклик, чем для тачскрина и виртуальной клавиатуры. Два других устройства с физическими кнопками — Gameboy Color и Kindle 4.
После «айфонов» и устройств с кнопками в таблице представлены разнообразные устройства Android различных годов. В самом низу древний Palm Pilot 1000 и пара электронных книг. Заторможенность Palm объясняется тачскрином и дисплеем из эпохи, когда технология тачскринов обеспечивала гораздо меньшую скорость. Электронные книги Kindle работают на электронных чернилах e-ink, которые гораздо медленнее дисплеев в современных телефонах, так что их отставание неудивительно.
Почему Apple 2e настолько быстр?
Система Apple 2 значительно выигрывает у современных компьютеров (кроме iPad Pro) по скорости ввода и вывода, поскольку Apple 2 не имеет дела с переключением контекстов, буферами при переключении разных процессов и т.д.
Если посмотреть на современные клавиатуры, то обычно ввод данных сканируется с частотой от 100 Гц до 200 Гц (например, Ergodox заявляет о частоте 167 Гц). Для сравнения, Apple 2e эффективно сканирует ввод на частоте 556 Гц. См. приложение с дополнительной информацией.
Если посмотреть на другой конец конвейера ввода-вывода, на дисплей, то здесь мы тоже можем найти источник задержки. Мой дисплей рекламирует задержку 1 мс, но если замерить реальное время от начала вывода символа на экран до полного его отображения, то там легко может оказаться и 10 мс. Этот эффект проявляется даже на некоторых дисплеях с высокой частотой обновления, которые продаются благодаря рекламе своего якобы быстрого отклика.
На 144 Гц каждый кадр занимает 7 мс. Изменение картинки на экране вызывает дополнительную задержку от 0 мс до 7 мс из-за ожидания границы следующего кадра перед его отрисовкой (в среднем мы ожидаем половины максимальной задержки, то есть 3,5 мс). Кроме того, даже хотя мой домашний дисплей заявляет о скорости переключения 1 мс, ему в реальности требуется 10 мс для полного изменения цвета с момента начала этого процесса. Если сложить задержку от ожидания следующего кадра с задержкой реального изменения цвета, то мы получим ожидаемую задержку 7/2 + 10 = 13,5 мс.
На старых ЭЛТ-мониторах Apple 2e мы ожидаем задержку в половину от частоты обновления 60 Гц (16,7 мс / 2), то есть 8,3 мс. Сегодня такой результат трудно превзойти: самый лучший «игровой монитор» способен уменьшить задержку примерно до таких значений, но с точки зрения рыночной доли такие дисплеи установлены на очень небольшом количестве систем, и даже мониторы, которые рекламируются как быстрые, на самом деле не всегда являются таковыми.
Конвейер рендеринга iOS
Если посмотреть на все процессы между вводом и выводом, то для перечисления различий Apple 2e с современными компьютерами придётся написать целую книгу. Чтобы получить картину происходящего на современных машинах, вот высокоуровневый набросок того, что происходит на iOS, от инженера iOS/UIKit Энди Матущака, хотя он называет это описание «своими устаревшими воспоминаниями устаревшей информации»:
Частота обновления и время отклика
Одна интересная вещь в тестировании времени отклика на компьютерах — это влияние частоты обновления экрана. При переходе с 24 Гц на 165 Гц мы ускоряемся на 90 мс. На 24 Гц отображение каждого кадра занимает 41,67 мс, а на 165 Гц — 6,061 мс. Как мы видели выше, без буферизации средняя задержка при обновлении фрейма составила бы 20,8 мс в первом случае и 3,03 мс во втором (поскольку мы ожидаем поступления кадра в случайной точке, а время ожидания случайно распределяется между 0 мс и максимальным временем ожидания), то есть разница составляет около 18 мс. Но в реальности разница 90 мс, что подразумевает задержку на (90 − 18) / (41,67 − 6,061) = 2 фрейма из буфера.
Сложность
Почти каждый компьютер или мобильное устройство сегодня медленнее, чем типичные компьютеры 70-х и 80-х. Игровые десктопы с низким временем отклика и iPad Pro могут сравниться с быстрыми машинами 30-40-летней давности, но большинство коммерческих моделей даже близко не стоят.
Если постараться определить главную причину увеличения времени отклика, то можно сказать, что это «сложность». Конечно, все знают, что сложность — это плохо. Если за последнее десятилетие вы посетили хотя бы одну ненаучную или некорпоративную технологическую конференцию, то с высокой вероятностью слышали хотя бы один доклад о том, что сложность — главная причина всех бед и как нужно стремиться к уменьшению сложности.
К сожалению, намного труднее это сделать в реальности, чем заявить со сцены. Сложность зачастую даёт нам определённые выгоды прямо или косвенно. Когда мы сравниваем ввод данных с модной современной клавиатуры и с клавиатуры Apple 2, то видим лишние задержки на обработку данных с клавиатуры мощным и ресурсоёмким процессором, по сравнению со специализированными логическими схемами для клавиатуры, которые проще и дешевле. Но использование процессора даёт возможность легко настраивать клавиатуру, а также переносит проблему «программирования» клавиатуры с аппаратной части на софт, что снижает стоимость производства клавиатур. Более дорогой чип увеличивает стоимость производства, но с учётом всех расходов на дизайн этих полукустарных мелкосерийных клавиатур, в целом выглядит так, что экономия от простого программирования перевешивает дополнительные расходы.
Мы видим такого рода компромиссы на каждом этапе конвейера. Нагляднее всего сравнение ОС на современном десктопе с циклом на Apple 2. Современные ОС позволяют программистам писать стандартный код, который будет работать одновременно с другими программами на той же машине, с довольно разумной общей производительностью, но за это мы платим огромную цену в увеличении сложности, а вовлечённые в многозадачность процессы легко приводят к значительному увеличению времени отклика.
Значительную часть сложности можно назвать случайной сложностью, но она присутствует здесь тоже в основном из-за удобства. На каждом уровне от аппаратной архитектуры и интерфейса syscall до фреймворка ввода-вывода мы наращиваем сложность, львиную долю которой можно устранить, если сегодня сесть и переписать все системы и их интерфейсы. Но слишком неудобно заново изобретать Вселенную для снижения сложности, а рост экономики даёт прибыль, так что мы живём с тем что имеем.
По этим и другим причинам на практике проблема снижения производительности, которая возникла из-за «излишней» сложности, часто решается ещё бóльшим усложнением системы. В частности, те достижения, которые позволили нам приблизиться к самым быстрым машинам 30-40-летней давности, получены не благодаря следованию увещеваниям об уменьшении сложности, а именно от дополнительного усложнения систем.
iPad Pro — это подвиг современного инжиниринга, где разработчики увеличили частоту обновления на устройствах и ввода, и вывода, а также оптимизировали программный конвейер для устранения ненужной буферизации. Дизайн и производство экранов с высокой частотой обновления, которые уменьшают время отклика — это нетривиально более сложная задача во многих отношениях, которые были необязательны во времена архаичных стандартных дисплеев на 60 Гц.
В реальности это обычное дело при попытке уменьшить задержку. Самый популярный трюк для этого — добавить кеш, но добавление кеша в систему увеличивает её сложность. Для систем, которые генерируют новые данные и не допускают использования кеша, предлагаются ещё более сложные решения. В качестве примера можно привести крупномасштабные системы RoCE. Они способны сократить задержку доступа к удалённым данным с миллисекунд до микросекунд, что открывает двери для нового класса приложений. Но это сделано за счёт увеличения сложности. Разработка и грамотная оптимизация первых крупномасштабных систем RoCE занимала десятки человеко-лет и требовала огромных усилий операционной поддержки.
Заключение
Выглядит немного парадоксально, что современная игровая машина, которая работает в 4000 раз быстрее Apple 2, где на процессоре в 500 000 раз больше транзисторов (а в GPU — в 2 000 000 раз больше транзисторов) с трудом выдаёт такую же скорость отклика, как Apple 2 — и то лишь в аккуратно написанных приложениях и только на мониторе с трёхкратной частотой обновления по сравнению с Apple 2. Ещё более абсурдно, что в PowerSpec G405 с конфигурацией по умолчанию — самом быстром компьютере по однопоточным вычислениям до октября 2017 года — задержка от нажатия клавиши до вывода на экран (примерно один метр, может, три метра реального кабеля) превышает время передачи пакета вокруг земного шара (26 000 км от Нью-Йорка через Лондон до Токио и обратно в Нью-Йорк).
С другой стороны, мы явно выходим из тёмных времён огромных задержек — и сегодня уже можно собрать компьютер или купить планшет с временем отклика в том же диапазоне, что у стандартных машин в 70-е и 80-е. Это немного напоминает тёмные времена разрешений экранов и размера пикселей, когда ЭЛТ-мониторы 90-х годов до относительно недавнего времени имели лучшие характеристики, чем стандартные ЖК-дисплеи настольных компьютеров. Сейчас наконец-то стали обычными дисплеи 4k, а дисплеи 8k опустились до нормальных цен — это не идёт ни в какое сравнение с коммерческими ЭЛТ-мониторами. Не знаю, произойдёт ли такой же прогресс со временем отклика, но будем надеяться на это.
Другие статьи об измерении отклика
Приложение: зачем замерять время отклика?
Отклик очень важен! В очень простых задачах люди способны различать отклик до 2 мс или меньше. Более того, увеличение задержки не только заметно пользователям, но и является причиной менее точного выполнения простых задач. Если хотите наглядной демонстрации, как выглядит задержка, а у вас нет старого компьютера под рукой, вот демо MSR по задержке тачскрина.
Производительность тоже имеет значение, но она хорошо понятна и часто измеряется. Если зайти практически на любой сайт с бенчмарками или открыть обычный обзор, то увидите огромное количество измерений производительности, так что дополнительные измерения здесь не имеют особой ценности.
Приложение: клавиатура Apple 2
Для справки, в клавиатуре Ergodox работает микроконтроллер на 16 МГц примерно с 80 тыс. транзисторов, а компьютере Apple 2e работает центральный процессор на 1 МГц с 3500 транзисторов.
Приложение: экспериментальная установка
Большинство измерений произведено на камеру 240 FPS (разрешение 4,167 мс). Устройства с временем отклика менее 40 мс были повторно измерены камерой на 1000 FPS (разрешение 1 мс). Результаты в таблицах являются результатом усреднения по итогу нескольких измерений и округлены до десяти, чтобы избежать впечатления ложной точности. Для настольных компьютеров время отклика соответствует времени от начала движения клавиши до окончания обновления экрана. Обратите внимание, что это отличается от большинства измерений key-to-screen-update, которые можно найти в интернете — в этих бенчмарках обычно используются установки, которые эффективно устраняют любую задержку клавиатуры. В качестве теста от начала до конца это реалистично только в том случае, если у вас установлена телепатическая связь с компьютером (хотя в таких измерениях тоже есть польза — если вам как программисту нужен воспроизводимый бенчмарк, то хорошо в тесте избавиться от факторов, которые находятся вне вашего контроля, но для конечных пользователей это не так).
Люди часто выступают за измерение одного из параметров: <нажатие клавиши до конца, срабатывание переключателя>. Кроме удобства, больше нет особых причин измерять что-либо из этого, но люди часто выдают эти результаты за «реальную» работу клавиатуры. Но они не зависят от реального времени срабатывания переключателя. Время между нажатием и активацией, также как время между ощущением отклика и активацией, произвольны и доступны для настройки. Когда тестер заявляет, что это «реальное» ощущение пользователя от срабатывания клавиатуры, это в общем означает, что пользователь не понимает принципов работы клавиатуры. Хотя такое возможно, я не вижу причин транслировать одно конкретное заблуждение о работе клавиатур в конкретную метрику, где люди яростно выступают за разные неверные убеждения. Более подробно о заблуждениях относительно клавиатур см. эту статью с измерениями времени отклика.
Ещё одно важное отличие — то, что измерения произведены с настройками, максимально близкими к настройкам ОС по умолчанию, поскольку примерно 0% пользователей меняют настройки дисплея для уменьшения буферизации, отключения компоновщика и т.д. Ожидание окончания обновления экрана тоже отличается от того, что измеряется в большинстве бенчмарков — большинство полагают, что обновление «закончено», когда регистрируется любое движение на экране. Ожидание завершения обновления аналогично времени «визуального завершения» в WebPagetest.
Результаты на компьютерах получены в консоли «по умолчанию» для данной системы (например, PowerShell на Windows, LXTerminal на Lubuntu), что легко может означать разницу в 20-30 мс между быстрой и медленной консолями. Между измерениями в консоли и измерением полного времени от начала до конца, результаты в этой статье должны быть медленнее, чем в других статьях на эту тему (где часто замеряется время до начала изменений на экране в играх).
Базовый результат PowerSpec G405 получен на встроенной графике (машина продаётся без видеокарты), а результат с 60 Гц — с дешёвой видеокартой.
Результаты для мобильных устройств получены в браузере по умолчанию после загрузки сайта https://danluu.com и замера задержки от движения пальца до первого перемещения картинки на экране, что сигнализирует о начале прокрутки. В тех случаях, когда такой тест не имел смысла (Kindle, Gameboy Color и др.), были сделаны другие осмысленные действия на этой платформе (перелистывание страницы на Kindle, нажатие джойстика в игре на Gameboy Color и т.д.). В отличие от измерений на десктопе или ноутбуке, эти измерения были до первого изменения на экране, чтобы избежать многих фреймов прокрутки. Для простоты измерений палец изначально касался экрана, а таймер включался, когда он начинал движение (чтобы избежать проблем с определением времени касания пальцем экрана).
В случае «равных» результатов порядок сортировки в таблице определялся по неокруглённому времени задержки, но это не следует считать важным фактором. Отличие на 10 мс тоже не следует считать значительным.
Машина на Haswell-E тестировалась и с включенной опцией G-Sync — заметной разницы не зафиксировано. Год выпуска для этого компьютера установлен в каком-то смысле произвольно, поскольку процессор 2014 года выпуска, а дисплей более новый (думаю, до 2015 года дисплеев на 165 Гц ещё не было).
Количество транзисторов на некоторых современных машинах приведено примерно, потому что точные цифры не разглашаются. Не стесняйтесь сообщить мне, если найдёте более точную оценку!
Все результаты под Linux сделаны на ядре до KPTI. Возможно, KPTI повлияет на задержку.
Работа ещё не закончена. Я собираюсь собрать бенчмарки с большего количества старых компьютеров во время следующего визита в Сиэтл. Если вы знаете о старых компьютерах, которые можно потестировать в районе Нью-Йорка (с оригинальными дисплеями или вроде того), дайте знать! Если у вас есть устройство, которое вы готовы пожертвовать для тестов, можете высылать на мой адрес:
Dan Luu
Recurse Center
455 Broadway, 2nd Floor
New York, NY 10013