Медленный софт

https://www.inkandswitch.com/slow-software.html
  • Перевод
От переводчика: проблема медленного программного обеспечения стала одной из главных тем обсуждения на Хабре и Hacker News в последние недели. Например, см. статью Никиты Прокопова «Моё разочарование в софте» и 2432 комментария к ней.

Мы проводим много времени за компьютером. Ждём каждый раз при запуске приложений и загрузке веб-страниц. Повсюду иконки со спиннером или песочными часами. Железо всё мощнее, но софт по-прежнему кажется медленным. Почему так?

Если вы используете компьютер для выполнения важной работы, то заслуживаете быстрого ПО. Слишком часто современный софт не удовлетворяет этим требованиям. В исследовательской лаборатории Ink & Switch мы изучили причины такой ситуации, программное обеспечение в итоге стало лучше. В этой статье опубликованы результаты нашего исследования.

Оглавление



Где именно ощущается медлительность


Что воспринимается пользователями как «медленная» программа? Всех нас иногда софт раздражает задержками и лагами. Но чтобы лучше понять эти проблемы, следует дополнить интуитивные ощущения академическими исследованиями, которые строго отвечают на данный вопрос.

Воспринимаемая скорость тесно связана с понятием задержки (latency). Сравнение научных исследований того, «что кажется медленным», с измерением реальной задержки в настоящих приложениях даёт понять, насколько всё плохо.

Задержка — это не пропускная способность


При обсуждении производительности программного обеспечения мы часто слышим о пропускной способности. Например, «этот веб-сервер может выполнять 10 000 запросов в секунду». Но это не то, как пользователи воспринимают вещи. Они заботятся о том, сколько времени занимает их конкретный веб-запрос или как долго занимает открытие документа, или как быстро приложение реагирует на нажатие мышки. Эти взаимодействия связаны с задержкой (latency). Задержка — это критическая метрика, которую мы будем изучать в данной статье.

Восприятие пользователем
Подробнее о важности задержки в интерактивных системах см. здесь.

На ощущение скорости ПО влияют и другие факторы. Например, частота кадров и обратная связь во время длительных задач. Но мы считаем, что задержка — фундаментальная метрика, а при очень низкой задержке любое программное обеспечение будет ощущаться как чрезвычайно быстрое.


Тач-интерфейсы


Для начала рассмотрим человеческую чувствительность к задержкам сенсорного экрана.

Исследователи проверяют это с помощью тестов, которые точно определяют, какую задержку воспринимают пользователи. Сначала испытуемым предлагают интерфейс, имеющий (скажем) задержку 1 мс, а потом (скажем) 70 мс, и просят выполнять операции вроде нажатия кнопки. Если интерфейс 70 мс последовательно показывает худший результат, чем интерфейс 1 мс, то 70 мс называют «заметной разницей».

Минимально заметная разница
Подробнее о минимально заметной разнице задержки и связанных с ними экспериментальных установках см., например, эту работу.


Минимально заметная разница — это бюджет, по исчерпании которого конкретная операция начнёт ощущаться медленной для пользователя.

Например, при перетаскивании элементов на экране пользователи воспринимают задержки всего в ~2 мс. Наименее заметная задержка зависит от пользователя и выполняемого действия, но она всегда очень низкая.

Восприятие задержки при перетаскивании
Отчёт о восприятии 2−16 мс при перетаскивании стилусом.
2−11 мс при перетаскивании пальцем.
В среднем 11 мс при перетаскивании пальцем.


Аналогичные результаты получены при рисовании стилусом на планшете. Здесь исследователи предлагали пользователям заметить задержку от 20 до 80 мс. В наших собственных неофициальных тестах задержка около 80 мс воспринимается как очень заметная, и требуется что-то гораздо ближе к 20 мс, чтобы стилус казался отзывчивым во время рукописного ввода.

Восприятие задержки стилуса
Отчет о восприятии задержки 10−70 мс при письме стилусом.
21−82 мс для различных действий со стилусом.


Разница между низкой и высокой задержкой рукописного ввода очевидна при сравнении:

Слева: iPad Pro и приложение Notes со сквозной задержкой около 15 мс. Справа: приложение Samsung S3 и OneNote с задержкой около 70 мс. Видео замедлено в 16 раз.

Другая типичная операция на сенсорных устройствах — нажатие на кнопки или ссылки. Здесь тесты определили, что пользователи замечают задержку примерно на рубеже 70 мс (хотя у некоторых отдельных пользователей она, вероятно, ниже).

Восприятие задержки нажатия на экран
Данное исследование выявило среднюю минимально различимую задержку в 69 мс.


Вот пример, сравнивающий две разные задержки:

Слева: открытие вкладки настроек на iPhone 6s с задержкой около 90 мс. Справа: переключение настройки на Samsung S3 с задержкой около 330 мс. Видео замедлено в 16 раз.

Насколько современные приложения соответствуют этим пороговым значениям? Если говорить о перетаскивании пальцем, то ни одна коммерческая система не способна постоянно соответствовать задержке в несколько миллисекунд, чтобы удовлетворить всех потребителей.

Производительность перетаскивания
Как мы увидим ниже, в бюджет 10 мс не вписываются даже дисплеи и оборудование для ввода данных, не говоря уже о нескольких слоях программного обеспечения.


Таким образом, при использовании всех текущих ОС с сенсорным экраном по крайней мере часть пользователей будет ощущать, что объект при перетаскивании отстаёт от пальца.

При рисовании стилусом небольшое количество систем приближается к приемлемо низкому уровню задержки. Но большинство из них намного выше этих значений, что ожидаемо ощущается пользователями как значительная задержка:

Ниже представлены результаты тестов Ink & Switch по задержке рисования стилусом на планшете для различных устройств. Средние задержки, измеренные от контакта с экраном до начала изменения цвета соответствующего пикселя, округляются до ближайших 5 мс.

Устройство Программа Задержка (мс)
iPad Pro Notes 20
GoodNotes 30
Flutter 35
Surface Pro OneNote 25
SketchPad 30
Canvas 60
Pixelbook Squid 40
Canvas 60
Samsung S3 Squid 60
Flutter 65
Canvas 75
LiveBoard 80

Хотя у нас нет данных о задержках на всех устройствах, но мы предполагаем, что они сопоставимы с задержками рисования стилусом, наблюдаемыми выше.

Задержки рисования по сравнению с задержками нажатия
Мы ожидаем, что эти задержки сопоставимы, потому что в обоих случаях используется сенсорный ввод, то есть задействуется цикл обновления экрана. Тем не менее, есть некоторые различия, поэтому вряд ли значения будут в точности одинаковыми.


Поскольку здесь различимой является задержка около 70 мс, большинство систем способны хорошо реагировать на нажатия. Но также легко найти приложения, которые работают намного хуже, чем теоретические возможности системы.

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

Клавиатура


Существует ряд свидетельств того, что увеличение задержки при наборе текста ухудшает работу пользователей.

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


Тем не менее, мы не знаем об исследованиях, специально измеряющих наименее заметные задержки ввода. Задержка нажатия на сенсорный экран (заметная на примерно 70 мс) может быть полезным ориентиром, потому что она также измеряет время между дискретным прикосновение пальца и визуальным обновлением экрана.

Ниже приведены некоторые неформальные измерения сквозной задержки клавиатуры от начала нажатия клавиши до появления символа на различных машинах. Источники: «Задержка компьютера: 1977−2017», тесты Ink & Switch.

Компьютер Задержка (мс)
Apple IIe 30
Commodore Pet 4016 60
iMac g4 OS 9 70
Macbook Pro 2014 100
Custom Haswell-e 24Hz 140
Samsung S3 150
Powerspec g405 Linux 170
Symbolics 3620 300

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

Мышь


Последний тип устройств ввода в нашем обзоре. Один эксперимент позволил определить, что пользователи воспринимают задержку мыши начиная от 34 до 137 мс со средним значением 65 мс.

У разных мышей очень сильно отличаются значения задержки. Некоторые системы показывают значения менее 10 мс путём совмещения высокопроизводительного оборудования с тщательным низкоуровневым программированием (здесь описана установка с задержкой около 8 мс). Кроме того, можно выйти за рамки 100 мс на сочетании посредственного оборудования и приложений, которые вводят дополнительные задержки, или буферов между мышью и дисплеем.

Приложения


Задержки на уровне приложений измеряют, сколько времени требуется для выполнения конкретных действий приложения, таких как загрузка веб-страниц. Пример такой задержки — загрузка веб-страницы NYTimes, что требует около 3000 мс.


Когда действия приложений кажутся быстрыми? Трудно сказать точно, потому что их действия более сложны и разнообразны, чем простой ввод данных. Вероятно, ответ зависит также от ожиданий пользователей (в настоящее время обычно люди работают с медленным программным обеспечением). Но мы можем вычислить примерное число.

Литература по задержкам
См. обзор литературы о влиянии задержки на пользователей разных приложений. Это хорошая отправная точка для более глубокого погружения в тему.


Одно из опорных значений — типичная метрика в 70 мс как упомянутая выше наименее различимая задержка при нажатии на экран. Если вы заметили задержку между нажатием ссылки и отображением индикатора нажатия, то должны заметить аналогичную задержку между нажатием и открытием веб-страницы.

Ещё одно опорное значение — модель Google RAIL для разработчиков. Хотя авторы этой модели никак не обосновывают свои утверждения, однако модель утверждает, что отклик в пределах 100 мс «ощущается как мгновенный», а более высокая задержка «[разрывает] связь между действием и реакцией».

Вы можете неофициально проверить собственную чувствительность в терминале. Возьмите любимые программы командной строки и запустите их с параметром 'time', который замеряет время выполнения. Наверняка заметите разницу между ответами за 15 мс (отлично!) и 500 мс (очевидно медленный).



В качестве конечной опорной точки учтём, что типичное время реакции человека на визуальный стимул составляет около 220 мс.

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

Нужно также учесть выводы некоторых исследователей, что человек способен воспринимать увеличение задержки на бессознательном, физиологическом уровне.

Реальные приложения


Как реальные приложения соответствуют этим ориентирам? Некоторые справляются. Например, многие программы командной строки Unix работают быстрее 100 мс.

Но бóльшая часть интернет-приложений выходит за допустимые рамки. Поиск в Google примерно за 1000 мс гораздо быстрее, чем большинство веб-приложений, но всё равно заметно медленнее по сравнению со взаимодействием менее 100 мс в командной строке. И легко найти примеры страниц, которые загружаются дольше 5000 мс даже на хорошем соединении.

В случае мобильных и настольных компьютеров есть некоторые приложения, которые последовательно демонстрируют задержку менее 100 мс, такие как встроенный калькулятор на iOS. Но легко найти примеры приложений, которые значительно превышают этот порог, даже если у них все данные доступны (или должны быть) локально. Рассмотрим пример Slack.

На видео ниже показано, что переключение между двумя малообъёмными каналами в той же рабочей области на iPad Pro занимает около 220 мс, хотя здесь нет необходимости в сетевых вызовах, а iPad Pro — возможно, самое высокопроизводительное мобильное устройство в мире (видео замедлено в 8 раз):


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

Откуда приходит замедление


Таким образом, мы установили, что многие программы на самом деле работают медленно. Куда уходит всё это время и что мы можем оптимизировать? Рассмотрим этот вопрос, начиная с первого компонента в цепочке: устройства ввода.

Устройство ввода


Первый шаг в конвейере, который преобразует физические входные данные в обновления на экране — это обработка входных данных: преобразование контакта с сенсорным экраном, клавиатурой или мышью в цифровой сигнал для операционной системы. Здесь мы рассмотрим, сколько времени занимает этот шаг.

Начнем с клавиатур. В таблице приведены измеренные задержки от начала нажатия клавиши до сигнала на USB-хабе, с округлением до 5 мс (источник).

Клавиатура Задержка (мс)
Apple Magic 15
Das 3 25
Kinesis Freestyle2 30
Ergodox 40
Kinesis Advantage 50
Logitech MK360 60

Как можете убедиться, эти клавиатуры легко отбирают десятки миллисекунд из бюджета на самом первом шаге в конвейере обработки. Это из общего бюджета в 100 мс или меньше! Гораздо более подробно эта тема освещена в статье «Печать с удовольствием».

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

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

Частота дискретизации


Один из общих шаблонов — частота дискретизации. Во многих устройствах ввода оборудование «сканирует» или «дискретизирует» ввод с периодическим интервалом. Например, типичный потребительский тачскрин работает на частоте 60 Гц, то есть опрашивает сенсоры примерно каждые 17 мс. Это означает, что в худшем случае задержка устройства ввода составит не менее 17 мс, а в среднем не более 8 мс.

При прочих равных условиях более высокая частота сканирования уменьшит задержку ввода. Например, передовые тачскрины и стилусы Apple работают на частоте выше 60 Гц (информация из архива документации Apple).

Устройство Тачскрин (Гц) Стилус (Гц)
iPhone 6 60
iPhone 7 60
iPhone 8 60
iPhone X 120
iPad Air 2 60
iPad Mini 4 60
iPad Pro 120 240

Аналогичный источник задержки — опрос USB. Протокол USB получает входной сигнал от клавиатуры, поэтому клавиатуре нужно ждать опроса USB, чтобы отправить информацию о нажатиях. Низкоскоростной USB-опрос работает на 125 Гц, вводя неизбежные ~8 мс макс. и ~4 мс средней задержки. Более поздние версии USB сканируют с частотой 1000 Гц и более, сводя к минимуму влияние задержки.

Существует много других потенциальных источников задержки в устройствах ввода, например, дребезг контактов (подробнее см. статью «Сканирование клавиатурной матрицы и дребезг контактов» о программных и аппаратных последствиях дребезга).

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

Дисплеи и графические процессоры


Аппаратное обеспечение на другом конце конвейера — это дисплеи и видеокарты.

Одним из источников задержки здесь является частота кадров дисплея. Поскольку дисплеи не могут перерисовываться постоянно, это приводит к неизбежной задержке, аналогичной опросу устройств ввода, описанной выше. Если экран обновляется (скажем) каждые 20 мс, то добавляет 20 мс задержки в худшем случае и 10 мс в среднем.

Восприятие движения
На наше восприятие движущихся на экране объектов влияют и другие факторы. Blur Busters — отличный ресурс на эту тему. Например, см. LCD Motion Artifacts 101.


Большинство дисплеев работают на частоте 60 Гц, хотя профессиональные устройства и игровые дисплеи работают на 120 Гц, 144 Гц и 240 Гц. Таким образом, только частота кадров дисплея обычно добавляет к задержке в среднем около 8 мс, хотя в дисплеях с самой высокой частотой кадров она может быть уменьшена до нескольких миллисекунд.

Другой вклад в задержку от дисплеев — время, затрачиваемое на физическое изменение цвета пикселей после получения новых данных. Это время варьируется от нескольких миллисекунд в высококлассных игровых дисплеев до двузначных значений в менее отзывчивых ЖК-дисплеях.

Время отклика дисплея
Этот параметр трудно измерить, но некоторые иллюстративные данные есть на сайте Notebook Check. Например, см. пример медленного и быстрого дисплеев.


На современных устройствах высокого класса дисплей подключен к специальному графическому процессору (GPU). Графические процессоры создают массив пикселей для отображения, например, путём компоновки слоёв 2D или рендеринга виртуальных сцен 3D. Графические процессоры производят кадры со скоростью, которая зависит от оборудования GPU, взаимодействия с приложением и кодом платформы, а иногда и от логики синхронизации с дисплеями.

Связанная с этим проблема возникает, когда код приложения работает очень медленно и недостаточно быстро отправляет инструкции в GPU, чтобы в полной мере использовать его. Это может привести к тому, что графический процессор будет создавать уникальные кадры с более низкой скоростью, чем если бы он действительно имел частые инструкции от приложения. Это общий источник лагов, которые мы видим в 2D-приложениях, отображающих менее 60 кадров в секунду.

Лаги
Лаги типа 'jank' трудно описать словами, но они легко узнаваемы. Натан Гиттер в статье Designing Jank-Free Apps определяет их как «визуальные сбои, которые являются неожиданными или отвлекающими».


Наложение циклов


Мы обсудили по крайней мере три части конвейера, где возникает задержка из-за периодической активности: сканирование ввода, циклы визуализации GPU и циклы обновления дисплея. Важно отметить, что они могут сочетаться таким образом, что по сути все задержки складываются:


Ожидание нескольких циклов. Гипотетический каскад задержки показывает, как ожидание последовательных аппаратных циклов может накапливать задержку. Пунктирные вертикальные линии показывают циклы, которые должен ожидать конвейер

Чтобы перейти к очередному шагу в конвейере, мы должны подождать наступления следующего цикла. И циклы могут быть не выровнены друг с другом. Несогласованные циклы и неблагоприятное начальное время ввода могут вызвать дополнительную задержку в 10 миллисекунд. Это большая величина по сравнению с бюджетами задержки, описанными выше.

Оверхед среды выполнения


На стороне программного обеспечения задержки времени выполнения присущи операционным системам и другому коду, который не относится непосредственно к приложению. Рассмотрим два важных примера: сборка мусора и диспетчеризация (шедулинг).

Сначала идёт сборка мусора (GC). GC имеет решающее значение в двух наиболее широко используемых платформах в мире: веб (JavaScript) и Android (Java).

В некоторых случаях сборка мусора может привести к большой задержке, особенно относительно требований к малой задержке ввода. Для сред JavaScript или Java не удивительны задержки на сборку мусора порядка 10 мс. Но это полностью весь бюджет для перетаскивания объектов на сенсорном экране!

Сборка мусора может задержать всего один кадр. Но как и в случае с лагами из-за потери кадров, такие рывки раздражают пользователей.

Существуют способы уменьшения задержки GC. Они включают в себя перемещение как можно большего количества работы GC за пределы основного потока, а также оптимизацию работы GC только в небольшие отдельные паузы. См., например, усилия V8 по перемещению как можно больше операций по сборке мусора за пределы основного потока и усилия разработчиков Go, чтобы максимальные лаги GC были значительно меньше 1 мс.

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

Другим потенциальным источником оверхеда является шедулинг в операционной системе. Наше приложение (и его зависимости в ОС) не обязательно работают постоянно. Другие программы могут быть запланированы на запуск, а наша принудительно приостановлена, пусть на очень короткое время. Каждая программа просит время, а количество ядер процессора ограничено.

С проблемой диспетчеризации связана загрузка CPU. Если ваше приложение отвечает своим целям производительности, но для этого требует почти 100% вычислительных ресурсов, это вполне может раздражать пользователей. Увеличится расход заряда батареи, устройство нагреется и, возможно, начнёт шуметь вентилятором. Другими словами, при прочих равных низкая загрузка CPU лучше для пользователя.

Умышленная задержка


Типичный источник задержек в мобильных интерфейсах — дизайн самой ОС и приложений. Есть некоторые важные взаимодействия, которые можно совершить только путём реального ожидания.

Android и iOS в значительной степени используют «долгое нажатие» для доступа к контекстным меню. Они требуют, чтобы пользователь ждал сотни миллисекунд для выполнения команды.

С этим связаны задержки для устранения неясностей. Например, в мобильном Safari есть задержка по умолчанию 350 мс между тем, когда пользователь нажимает на ссылку, и когда браузер начинает загружать новую страницу. Это нужно для определения разницы между щелчком по ссылке и двойным касанием (зум). По поводу этой конкретной задержки подробнее см. здесь. Там же информация о последних изменениях, которые позволяют разработчикам приложений обойти эту проблему.

Враждебные агенты


Распространённый источник задержки для пользователей в интернете — вредоносные активности, например, трекеры активности, которые отслеживают действия пользователей и загружают навязчивую рекламу.


Статья из 500 слов на сайте Washington Post требует около сотни HTTP-запросов и загружается примерно 4400 мс. Многие запросы нужны для трекеров и рекламы. Показана небольшая их часть

Есть много замечательных статей об ожирении веба: см. The Bullshit Web, «Кризис ожирения сайтов», Web bloat и др.

Просто подчеркнём, что самым большим источником задержки на многих сайтах является загрузка всякой ерунды против желания пользователей.

Код приложения


Последний источник задержки, который мы упомянем — он пожалуй, самый очевидный: это само приложение. Если приложение тратит много процессорного времени на обработку ввода или выполнение какого-либо действия, то оно будет медленным.

Соберём всё вместе


Рассмотрим пример, из чего складывается общая задержка:


Гипотетический пример сквозной задержки от ввода до отображения на экране. Пунктирные вертикальные линии показывают циклы, которые конвейер должен ожидать

Приведённый выше пример гипотетический, но показательный. Он демонстрирует, как много слоёв добавляют задержку, так что приложение может быть довольно медленным, даже если оно работает на полной частоте кадров.

К быстрому программному обеспечению


За реагирование современного компьютерного интерфейса на действия пользователя отвечает глубокий стек технологий. Даже простое нажатие клавиши на клавиатуре и появление соответствующего символа в текстовом поле ввода — это операция, которая проходит через длительную сложную последовательность шагов: от сканирования клавиатуры, через слои обработки ОС и фреймворка, через рендеринг видеокарты и частоту обновления дисплея.

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

Мы считаем, что быстрое программное обеспечение расширяет возможности пользователей и делает их более продуктивными. Мы знаем, что сегодняшний софт часто подводит пользователей, будучи медленным, и мы хотим улучшить ситуацию. Надеемся, что этот материал будет вам полезен при работе над собственным программным обеспечением.

Литература


1. Эндо, Ванг, Чен, Зельцер. «Оценка эффективности интерактивной системы с помощью задержки», Proceedings of the USENIX 2nd Symposium on Operating Systems Design and Implementation, 1996.

2. Нг, Аннетт, Дитц, Гупта, Бишоф. «В мгновение ока: исследование восприятия задержки при взаимодействии со стилусом», Proceedings of the 32nd Annual ACM Conference on Human Factors in Computing Systems, 2014.

3. Нг, Лепински, Вигдор, Сандерс, Дитц. «Разработка устройств с прямым тач-вводом с низкой задержкой», Proceedings of the 25th Annual ACM Symposium on User Interface Software and Technology, 2012.

4. Дебер, Джота, Форлайнс, Вигдор. «Какой скорости достаточно? Восприятие пользователем задержки и её улучшения в прямых и опосредованных тач-интерфейсах», Proceedings of the 33rd Annual ACM Conference on Human Factors in Computing Systems, 2015.

5. Аннетт, Нг, Дитц, Бишоф, Гупта. «До какого уровня следует опуститься? Понимание восприятия задержки при рисовании», Proceedings of Graphics Interface 2014, 2014.

6. Форч, Франке, Раух, Кремс. «Достаточно ли 100 мс? Характеристика порогового восприятия задержки при взаимодействии с мышью», Engineering Psychology and Cognitive Ergonomics: Cognition and Design, 2017.

7. Дабровски, Мансон. «40 лет поиска лучшего времени отклика компьютерной системы», Interacting with Computers, 2011.

8. Барреда-Ангелес, Арапакис, Баи, Камбазоглу, Переда. «Влияние бессознательных физиологических эффектов задержки поиска на пользователей и их щелчки мышью», 38th International ACM SIGIR Conference on Research and Development in Information Retrieval, 2015.
Поделиться публикацией
Комментарии 66
    +15
    Лаги софта раздражают еще, помимо очевидного. описанного в статье и тем, что не дают обратной связи на действие пользователю. Скажем, если я щелкнул выключателем — я заведомо знаю, что я включил, ну, скажем, старый ламповый телевизор и жду «лаг» в виде его прогрева, так же могут быть иные средства обратной связи — индикаторы включения, шум устройства. А когда я кликаю по ярлыку, и ничего не происходит — сижу и думаю: то ли я не кликнул, то ли висит система, то ли программа «раздумывает» перед запуском, то ли что-то еще произошло. И это бесит.
    А вот за лаги мобильных устройств типа «скролил экран, он тупит, нажал на экранную кнопку, но экран сдвинулся дальше, и в области нажатия оказалась совсем другая кнопка» создателей этих устройств надо вешать на фонарях. Особенно «весело» с такими закидонами серфить по инету без адблока.
      +1
      Вы еще не пытались читать уникальный контент на сайтах, увешанных выскакивающими баннерами, половина который появляется при нажатии чего-либо на сайте. Эти сайты виснут даже на iphone x моего знакомого, не говоря уже про мой j330f
        0
        Ладно скролил, яндекс-телепрограмма своей рекламой сдвигает страницу после загрузки (и не только она) и если кликнул, то оно съехало и кликнулось не туда.
        –1
        Статья чересчур умная, как мне кажется. Наверное, львиная часть тормозов софта из-за того, что для решения какой-то задачи зачастую подключается куча библиотек, вместо того, чтобы оформить все 20 строчками кода.
        Даже эффективные грамотные фреймворки дают огромный ненужный оферхед.

        У мобильников основное торможение из-за нехватки памяти и множества не оптимизированных фоновых процессов.
          +1
          Обычная ситуация: простенькая с виду страничка без особой функциональности подключает пару десятков JS-скриптов, и большинство из которых используется на пару процентов. Вместо того, чтобы написать те же 20 строк кастомного кода, подключается нечто огромное и стозевное, найденное в гугле, с кучей неиспользуемых наворотов на все случаи жизни.
            +1
            Буквально на днях, работая над только начавшимся проектом, решил было использовать DataTables для отображения таблицы с пользователями (тем более под Laravel есть плагин-связка с DataTables). Скачал — 500kB, в минифицированном виде — 80. В итоге написал всю необходимую функциональность в 50 строках JS/jQuery (а можно было и без jQuery обойтись, но он и так используется уже).
              0
              Ладно подключается и лежит, оно инициализироваться норовит на старте, а это время и память.
              +1
              Решил попробовать фреймворк Laravel. Поставил Composer, создал пустой проект. Сколько у меня исходного кода от разных вендоров в голом приложении? 38 штук! При этом у некоторых вендоров внутри куча пакетов. И кто-то может подумать что вся эта куча кода может быстро работать на сервере?
                +2
                Простая страница с доступом к БД в Laravel подключает ~350 файлов (это один запрос к серверу). Проверял через get_included_files().
                  +1
                  Только это одно означает, что 350 раз вызывается отдельно написанная на PHP функция для подключения классов по PSR. Это при том, что PHP и сам умеет подключать нужные файлы не вызывая никаких функций на PHP, но это не соответствует PSR, поэтому никем не используется.
                    0
                    Вообще-то composer это кэширует, в /vendor/composer
                +8
                Беда в том, что все эти слои абстракции, создаваемые различными фреймворками, прослойками и билиотеками никак не оптимизируются при сборке. По хорошему, все абстракции должны существовать только на бумаге, а при компиляции «схлопываться» в нативно исполняемый код. В реальности же каждый из слоев абстракции добавляет инициализацию кучи всего, что в вашем проекте не используется, многократное копирование данных, проверку входных параметров (на каждом слое заново!) и т.п. Плюс избыточное неуправляемое разрастание функциональности, которая нужна только 5% пользователей, но раз уж кому-то нужна, то без нее никак не обойтись.
                В итоге те решения, которые срабатывали мгновенно в TurboVision 25 лет назад на 486 ныне неспешно по 1-2 секунды реагируют на нажатия мыши.
                  0
                  не скажу про разрастание функциональности, но вот про постоянные проверки входных параметров и копирование данных на границах абстракций — прямо ужас.
                    +2
                    Я недавно ходил к другу отца, у него 98 винда и 386. Ох и летает она! В общем я часа полтора просто лазал по тому компу, тыкая везде и даже два раза разложил косынку. Я ещё клавишу/кнопку не отпустил, а уже все открылось. Я уж и не помню когда такое видел последний раз. Это я такое ощущение получил при том, что дома у меня комп с четырьмя ядрами, 2.8ггц, 16 гб оперативки и отключенным свопом. А ноутбук мой с двумя гигами оперативки вообще от трупа малоотличим (спасибо дебиан, десятка на нем вообще толком не работала).
                  +2

                  Samsung S3, Mac Book Pro 2014, список литературы, в котором на первом месте статья из прошлого века.


                  Вы серьёзно?


                  p.s. с самим посылом я в целом согласен
                  p.p.s. да, я видел что это первож

                    0
                    В каком именно месте современный НТП сделал первую статью рудиментарной?
                      +1

                      Я не утверждаю что статья рудиментарная, но видеть ее вверху списка немного странно. Хотя бы потому что понятие «интерактивная система» существенно изменилась за последние 22 года.


                      К примеру, в 96 году IDE с обыкновенным, не очень умным автодополнением, — это было уже что-то почти фантастическое (если вообще было), а сейчас считается нормальным иметь real-time solution-wide-error-analysis и фоновое исполненение юнит тестов. Просто другой уровень...


                      Психологический эффект наверное такой же остался, но производительность работы с компьютером возросла на порядки — даже с учётом «тормозов». Я бы не хотел променять все эти современные нововведения на интерфейс с около-нулевой задержкой.

                        0
                        а сейчас считается нормальным иметь real-time solution-wide-error-analysis и фоновое исполненение юнит тестов

                        Это всё ещё фантастика на сколь-нибудь больших проектах, когда запускаешь анализ и молишься, чтобы упало меньше семи раз.
                          0
                          Пардон, но статья ведь не об IDE, запускающих проекты на миллионы строк. Речь про веб-сайтики, приложения на андроид. И когда они дико тормозят, то нужно понимать откуда такие задержки.
                            +1
                            Во-первых, не понимаю, как понятие «интерактивная система» или ее основные концепции изменились за 20 лет, и почему важно, что оно на первом месте в списке литературы.

                            Во-вторых, вы про IDE из 96 года просто для примера или из личного опыта? Потому что в конце 90-х я писал на JBuilder, сейчас на Eclipse, и по сути писал одно и тоже — J2EE. И нормально писалось, с автодополнениями. Я прикинул — сейчас памяти в моем компе примерно в 50-100 раз больше, и процессор по флопсам наверно на столько же мощней, но у меня стойкое ощущение, что Eclipse выбешивает меня своими тормозами побольше, чем тот JBuilder.

                            Поэтому возрастание удобства работы разработчика со временем из-за НТП — это иллюзия. К каждому мощному новому железу в довесок идет груз «мощного» софта который нивелирует все достижения интелловских инженеров.

                            Основные программы и IDE 20 лет назад работали примерно с той же скоростью и отзывчивостью, что и сейчас (по ощущениям), а до динамики первого quake'a ни один современный шутер и близко не подходит.

                            Чтобы написать простой сервлет 20 лет назад надо было P-II 266 с 64Mb RAM. Сейчас для этой же самой задачи надо Core i-5 с 6Gb RAM. Где логика?
                              0
                              а что не дает сейчас писать простые сервлеты на P-II 266 с 64Mb RAM?
                                –1
                                В вашем вопросе есть какой-то смысл?
                                Потому что он от меня ускользает.
                                  0
                                  Чтобы написать простой сервлет 20 лет назад надо было P-II 266 с 64Mb RAM. Сейчас для этой же самой задачи надо Core i-5 с 6Gb RAM.

                                  вы утверждаете, что 20 лет назад можно было написать простой сервлет с P-II 266 с 64Mb RAM, а сейчас нельзя взять P-II 266 с 64Mb RAM и написать простой сервлет? если да, то почему нельзя?
                                    –1
                                    Можно взять и написать
                                    В чем вопрос?
                                      0
                                      Чтобы написать простой сервлет 20 лет назад надо было P-II 266 с 64Mb RAM. Сейчас для этой же самой задачи надо Core i-5 с 6Gb RAM. Где логика?

                                      к чему это?
                                        –1
                                        Вы не видите логики? Я тоже. Смотрите, специально же даже написал: Где логика?
                                        Я рад, что мы мыслим в одном направлении.
                                        Всего хорошего.
                                          0
                                          вопрос был другой, но ладно
                                          и вам всего хорошего
                        +4
                        О чем в принципе можно говорить, если вот эта конкретная страница, на которой на данный момент есть аж целых 33 килобайта текста (включая пробелы и знаки препинания), занимает в памяти компьютера 160 с мелочью мегабайт? Не считая гигабайта, который занимает остальной веб браузер и двух гигабайт, которые заняты другими вкладками в этом веб браузере?
                        Откуда смогут взяться «низакая латентность» и «высокая пропускная способность»?
                          –2

                          Вы же в курсе, что рабочее время программиста стоит дороже этих гигабайтов памяти.

                            +9
                            А мое рабочее время, когда у меня из-за установленного автокада запущено 4 хромиум хост экзекьютабл, которые жрут у меня на рабочем ноуте 10-20% процессора? Это при не запущенном автокаде! А если запустить автокад не прибив хром, или хотябы вкладки с хабром и новостными лентами, начинается своппинг, несмотря на установленные максимальные для моего ноута 16 гигов памяти… И все встает колом. И банальный альт-таб из автокада в аутлук — развлечение на десятки секунд.
                            Можно еще попробовать поразвлекаться на тему, сколько времени теряют проектировщики с зарплатой 100 килорублей, ПМ-ы с зарплатой 100-150 килорублей, ГИПы с зарплатой 150-250 килорублей, и ГАПы с зарплатой в 300-500 килорублей в месяц в не очень крутых строительных компаниях одной только России в сравнении с тем, сколько денег сэкономлено на рабочем времени программистов.
                            Поверьте мне, даже самые дорогие программисты Земли будут нервно курить в сторонке. Ибо на одного «самого дорогого» программиста приходятся тысячи проектировщиков, сотни ПМ-ов и десятки ГИПов и ГАПов.
                              +3

                              У меня там тег <сарказм> не вставился из-за перегрузки процессора в процессе написания комментария :) Ваши бы слова да богу программистов в уши. Вот сижу черчу в 2012 автокаде и слушаю музычку в медиаплеере, все летает, но тот же хабр могу просматривать исключительно только в мобильной версии, иначе, судя по звукам вентилятора, какой-то майнер запускается. Зато две вкладки мобильного хабра в файрфоксе съели 500 МБ, а 4 файла проектов в автокаде всего 200 МБ.

                                +3
                                Занятно. Мне иногда приходиться использовать Автокад как чертилку с некоторыми «плюшками». Пришлось потратить время, чтобы на торрентах отыскать ACAD 2006. Установлен параллельно с более «новым» 2012. По собственному опыту и по описаниям на форумах ACAD 2006 MD — последняя версия, которая запускалась мгновенно с холодного старта даже на древнем компьютере. Сейчас 2012 версия запускается 23 сек на стационарном i7 с 16 Гб ОЗУ (про более новые версии ACAD я вообще молчу).
                                Причем по функционалу отличий 2006 от 2012 я особо не вижу, кроме более современного интерфейса (может это мне не приходиться пользоваться какими-то навороченными библиотеками). В старой версии работаю как на фортепиано, все отзывчиво. В новой — может и призадуматься.
                                  +1
                                  Та же хрень с ABBYY Lingvo
                                  Мудрые хранят как зеницу ока 6 версию, хотя лет десять уже выпуcкаются новые крутые версии Lingvo
                                    +1

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

                                      +2

                                      Кстати, 2006-ой автокад запускался мгновенно, т.к. был нативным приложением, а потом автодески подсели на .net.

                                    +3

                                    Рабочее время программиста оплачивает разработчик софта, а ваше рабочее время — ваш работодатель. Экономия миллиона вашему работодателю за счёт скорости софта никак не отразится на кошельке разработчика софта. К сожалению. Надеюсь, появится платежеспособный спрос, тогда и предложение подтянется.

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

                                      Я боюсь, что пока мы, программисты, не напишем программу сбора статистики. Которая посчитает потерянные часы рабочего времени — мнение людей, которые оплачивают покупки не сменить.
                                        0
                                        И это всё равно не поможет. Потому что тормозит огромный слой legacy. Тот же AutoDesk не сможет что-то принципиально переписать, не отказавшись от столетних фич. Да и зачём ему что-то сильно переписывать, если и так купят. А перейти на другую, быструю программу, но несовместимую, пользователи не смогут.
                                          +1
                                          Тот же AutoDesk не сможет что-то принципиально переписать

                                          Помню я… чертил я в автокаде кое что в 1993-м году. Там уже были макросы на Лиспе, динамические блоки и примерно весь функционал, который нужен в реальной жизни большинству проектировщиков. Я думаю, что если сейчас запустить его на современной железке в эмуляторе — летать будет круче прежнего. И памяти будет кушать что-нибудь типа 4 мегабайт, вместе с эмулятором… А вот чтобы автокад со всем своим высокоэффективным легаси из времен 286-х процессоров летал не слишком быстро и тормозил на 8 гигабайтах памяти — вот для этого разработчикам пришлось серьезно попотеть…
                                            0
                                            Фичи-то добавляются. Приложение под 93-й автокад как-то дожило до современного, но приложение с последнего не запустится на 93-м, а значит, такой автокад не поставишь.
                                      0
                                      Надо все же признать что хром ест cpu только при активной работе. Ну или ноут на селероне, но вы говорите про автокад, поэтому откидываю этот вариант.
                                      +2
                                      Ну и да, дурацкий вопрос, но куда ушли 159967 килобайт памяти? На странице же всего текста было 33 килобайта! Ну ладно, еще 33 килобайта на тэги и разметку. Куда 159934 килобайта израсходовали? Я не смогу поверить, что это все съел подгруженный редактор комментариев. Я такого класса и уровня редактор (с подсветкой синтаксиса!!!) писал. Он весь был меньше 12 килобайт в скомпилированном виде (ради чего, собственно, и затевался, чтобы в доступных на тот момент 64 кБ оперативки поместить больше 32 кБ редактируемого текста...).
                                        0
                                        Распаршенный DOM, виртуальная машина с сэндбоксом…
                                          +1
                                          Ну и да, дурацкий вопрос, но куда ушли 159967 килобайт памяти?
                                          Напомнило чо та...

                                      +1
                                      Картинки, файл шрифта, JS, CSS, и т.д. Тут есть много чего ещё до того, как оно превратится в объекты представляющие это в оперативной памяти.
                                        0
                                        Вы видео учитывали? Я понимаю, что в норме это были бы десятки и сотни килобайт на один плейсхолдер незагруженного видео, но ведь пара порядков там вполне может потеряться.
                                        +4
                                        Основная беда в том, что абсолютное большинство пользователей, не смотря на все исследования, или не замечают лагов, или считают их нормой. Поэтому меню телефонов, телевизоров, банкоматов и прочих терминалов самообслуживания сплошь и рядом позволяют себе задержки в 1000-1500-100500 мс. и это почему-то почти никого не раздражает. Удивляюсь, как руль и тормоз в автомобилях еще не начали лагать на секунду-другую при таком отношении.
                                          0
                                          Вообще-то, лаг тормозов автомобиля как раз в секунду считается.
                                            +1

                                            Пользователи замечают, но их же не спрашивают. Знаю человека принципиально сидящего на айфонах из-за меньших лагов, для него это важно.

                                            0
                                            А так всё хорошо начиналось. Вроде и проблему хорошо выделили, и причину её возникновения описали хорошо. А в конце всё равно «мышки станьте ёжиками» в смысле «давайте просто возьмём, и станем делать лучше». При этом внятных соображений, как можно «делать лучше» не увеличивая при этом в разы бюджет и время работы, естественно не предлагается.
                                              +5
                                              Программы тормозят из-за любви (разработчиков-дизайнеров и пользователей) к «ми-ми-ми-шности». Все эти тени-полутени, закругленности, все эти анимации и т.п. Особенно к «реалистичности» всех этих наворотов, как будто реальность имеет отношение к виртуальному миру ПО. Я говорю о реальности тени, реальности эффекта нажатия на кнопку и т.п. хрени, которая никакой пользы не несет никому. Именно благодаря отсутствию всего этого в интерфейсе командной строки эти программы и летают.
                                              Выкиньте все те ракушки «3-дешности», «анимированности» и «реалистичности», что налипли на борта корабля под названьем ПО, и он понесется по волнам, как смазанная салом молния.
                                                0
                                                Мимишность продаётся, чуть меньший лаг — нет (в том числе разработчиками заказчику). Делают что приносит больше профита по отношению к затратам.
                                                  +1

                                                  Полутени и закругленности это же просто картинки, они вообще любыми могут быть, а анимации плавно работали еще в самом начале 2000ых.
                                                  То есть можно сделать плавный красивый UI с анимациями поверх простого rapsberry PI если заморочится.
                                                  Да, сейчас сильно увеличилась плотность пикселей, по сравнению с началом 2000ых, но блин и производительность железа ушла далеко вперед.
                                                  Тормозят на самом деле абстракции, которые имеют далеко не нулевую стоимость во время исполнения.

                                                    +1
                                                    это же просто картинки

                                                    Нет, это зачастую именно расчет теней. Это быстрее делается, настраивается, проще поддерживается. Но медленнее работает, да.

                                                      0
                                                      а анимации плавно работали еще в самом начале 2000ых

                                                      Это не так, я помню как тормозили фреймворки с красивостями по сравнению с нативным MFC.
                                                        0

                                                        А я помню интерфесы в игрушках. Они почему то содержали красивости, но не лагали.

                                                        0
                                                        Это не «просто картинки» — вы вспомните о том, что все эти округлости — это прозрачность, да многослойная, т.к. одно на другое накладывается. Возьмем курсор мышки: изначально было две BMP-хи, одна маска, другая картинка. Как только придумали тень от мышки — надо просчитывать каждый пиксел этой тени, чтобы вычислить «приглушенный цвет фона» — это сколько работы прибавилось? Помножьте это на те самые скорости движения, и выйдет, что только рисованием мышки мы пожираем столько же ресурсов, сколько весь интерфейс командой строки. И так на каждый чих современного интерфейса: раньше ссылка подсвечивалась при наведении курсора просто «хоп!», а теперь — с анимацией, плавненько, и погасает подсветка так же плавненько, с анимацией… Это вам не просто картинки. Кстати, для, казалось бы, простого вывода картинки используется такой слой промежуточных функций, выделения памяти и т.п. накладных ресурсов, что не так все это и просто на самом деле. Тут ведь как в автомастерской: сосед по гаражу вам гайку закрутит за 5 минут, а в сервисе — менеджер составит планчик, рассчитает стоимость, кассир примет оплату, мастер даст задание механику, механик поставит машину на подъемник, открутит гайку, мастер примет работу, передаст менеджеру, менеджер поставит галочку в компьютере и выдаст вам машинку. Вот вам и просто. Зато «сервис».
                                                        To PKav: меня тоже это беспокоит. Но ничего сделать нельзя: если вы станете заставлять своих разработчиков делать «по-вашему», ваши работодатели вас заменят на более покладистого «индуса» — выпускать продукт надо быстро, а чтобы он работал быстро — не надо. Ничего личного, просто бизнес.
                                                          0
                                                          Да, на самом деле, всё не так страшно в этой области. Если объяснить руководству то, что индус постепенно подведет их под замену микроконтроллера на более мощный и компания потеряет деньги на серийном производстве, то вряд ли они останутся равнодушны.

                                                          А вот во всякой веб-разработке и сервисах проще купить и воткнуть ещё один блейд-центр в серверную стойку, чем заставить программистов писать код руками.
                                                        0
                                                        Сделать сайт «мимишным» с точки зрения ресурсов стоит очень недорого. Если руки из нужного места растут.
                                                        +3
                                                        А меня пугает то, что растет производительность микроконтроллеров встраиваемых систем. За 3 доллара можно купить 2-ядерный микроконтроллер с частотой 240 МГц и 8 Мб памяти. Это приводит к тому, что кривые тормозные библиотеки и фреймворки потянутся туда, и тормозить уже начнет не только компьютер и смартфон, но и погодная станция, панель управление лифтом и бортовой компьютер автомобиля.

                                                        Сам стараюсь не использовать библиотеки и писать код инициализации и обмена данными с внешними устройствами сам, оптимизируя всё с учетом архитектуры микроконтроллера (прерывания, DMA). И если вдруг мне доведется когда-то руководить программистами, буду заставлять их делать так же.
                                                          0

                                                          Ну есть ардуинка с библиотечками, есть еще Rust Embedded Workgroup, которые тоже пилят наборы библиотечек под контроллеры.
                                                          Так что так или иначе библиотеки проникают в embedded, но не вижу в этом ничего ужасного до тех пор, пока итоговые прошивки будут полностью соответствовать требованиям.

                                                            0
                                                            Ну если своя начинка у ардуины ещё туда-сюда, то вот библиотеки порой написаны так, что без слёз не взглянешь.

                                                            Хотя разок влетел в ситуацию, где надо было быстро дёргать пинами, тут-то и выяснилось, что digitalWrite — это целых ~14 мкс, а записать напрямую в порт ручками — всего-то 6 мкс.

                                                            Таких приколов по чуть-чуть на каждый слой, и вот уже всё лагает.
                                                          +3
                                                          По сути, боян сорокалетней а то и большей давности. В конце 60-х Hewlett Packard проводила исследования по клавиатурам и системам графического ввода информации. В 70-х IBM разработала требования к отзывчивости интерфейса и даже разработала требования к соответствующей аппаратно-программной архитектуре. Достаточно поднять их результаты и просто воспользоваться вместо тогшо, чтобы пиарить огрызки — человек за 40 тысяч лет не изменился, за сорок он тем более остался тем же.
                                                            0
                                                            От всех задержек избавиться не выйдет, но большую часть решает мощная система на 8700k/9900k/2700x. Главное чтобы когда эта сборка станет мейнстримом появилась новая сборка которая опять на голову выше народных i5.
                                                            Пока рецепт такой.
                                                              +2
                                                              Например, при перетаскивании элементов на экране пользователи воспринимают задержки всего в ~2 мс.

                                                              О каких задержках речь? Чтобы задержки в 2 мс хоть как-то влияли на то, что воспринимает пользователь, нужно чтобы дисплей работал на частоте 500 Hz. Чего я не понимаю?
                                                                0
                                                                А лучше на 1000 Hz, чтобы уверенно говорить о задержке в 2 мс, а не 3.

                                                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                              Самое читаемое