Pull to refresh

Comments 38

Зачем это, если во всех нормальных браузерах такие графики уже есть «из коробки»?

Firefox 50, пример скролла этой страницы - средний FPS 12.73, макс. 60, мин. 3.48


В Chrome по-любому есть что-то аналогичное.

Затем, что мы не видим этих графиков из JS?

А зачем на них «смотреть» из JS? Собирать какие-нибудь отчеты и отправлять на сервер? Так ваша считалка и будет составлять основную нагрузку. А для разработки штатных средств более чем достаточно.

Вы пункт "Бла бла бла" не читали? Для реализации чего-то типа graceful degradation в JS-рантайме?
К примеру, я сейчас делаю редактор списков который в реальном времени добавляет/убирает элементы, которые могут содержать пользовательские данные со сложной структурой. При превышении определенного порога по количеству элементов — редактор переключается в упрощенный режим, чтобы браузер продолжал его рендерить без тормозов. Мне вполне бы пригодился инструмент для автоматического определения этого порога.
Прошу отметить, что считалка не моя, я говорю о проблеме безотносительно данного конкретного решения, в котором тоже вижу некоторые недостатки. Вы знаете как сделать лучше?

… в котором тоже вижу некоторые недостатки

Видите — пишите что не так, оч интересно глянуть как вы считаете.

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

… которые будут смешиваться в очереди с тем,...

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

Ок, а что происходит с очередью вызовов не связанных с рендером DOM? В нее точно так-же встраиваются колбэки из requestAnimationFrame, как и из setTimeout/setInterval ведь? И если никакой анимации нет, а есть, к примеру, парсинг JSON — вызовы бенчмарка замедляют весь остальной код?

Как я понял из дискуссии ниже, он занимается разработкой каких-то сложных WebGL-приложений (возможно, игры), так что там рендер идет беспрерывно (даже если игрок стоит на месте, то движутся какие-нибудь облака, NPC и т.д.), а код бенчмарка и код отрисовки будет запущен в рамках одной итерации цикла отрисовки.

А вот для простых страничек — да, пускай там будет производительность хоть 100500 кадров в секунду, вопрос: откуда там вообще берутся эти кадры, если страница статична, ее можно было просто один раз записать в видеопамять, а потом бы уже видеокарта ее аппаратно блендила с остальными окнами.

Не, "он" пилит онлайн-редактор и просто хочет оградить пользователей от "выстрела в ногу", при котором их браузер не потянет ими же созданный документ =)

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

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


какой смысл в это время что-то анимировать

А анимировать не обязательно, нагрузку и перерисовку может создать сам пользователь, масштабируя окно или, к примеру, редактируя contenteditable.

Спасибо, за предложение. Веб-воркер — хорошая идея.
Ну, графики вам не нужны точно (а если нужны, то нажмите F12). Кроме того, вам придется держать некий буфер и постоянно считать для него среднее арифметическое (если брать только текущий FPS, то он может «прыгать» туда-сюда, из-за чего ваше приложение будет постоянно мерцать, переключаясь со слабой детализации на полную и обратно).
Вместо буфера у меня используется «точный счетчик», как раз чтобы не реагировать на возможные провалы 'быстрого счетчика'. Так что мерцание будет в самом критическом случае, когда либо совсем мертвый интефейс, либо хоть какой, но живой. Лично я за живой.
Так ваша считалка и будет составлять основную нагрузку.

Какой именно участок кода, по вашему мнению будет давать нагрузку? Если жмакните по ссылке на 'стенд', то увидите, что при запущенном счетчике и вашем бездействие, FPS будет 60. Так что о какой нагрузке речь, я не понимаю.
А зачем на них «смотреть» из JS?

Вот, в потом то и печаль, что разработчики даже не понимают зачем это нужно. Используя штатные средства, вы можете оценить производительность на конкретной машине с конкретной конфигурацией и конкретным js-движком. А что делать с остальными миллионами пользователей с их разнообразием железа, ОС и д.т.? Есть два варианта либо вы зайдете к каждому и запустите на его машине средства разработки в браузере, либо всем пользователям нужно иметь такую же конфигурацию аппаратно-программных средств как у вас.
Если жмакните по ссылке на 'стенд', то увидите, что при запущенном счетчике и вашем бездействие, FPS будет 60
Какая мне разница, какой у вас FPS? Открываю пустую страницу, Firefox потребляет 13% времени ЦП (у меня сейчас открыто много вкладок). Открываю ваш «стенд», потребление сразу растет до 20%, а если поводить над окном мышкой, то даже 30%.

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

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

Я не верю. Вы с WebGL дело имели? А с Web VR? А мой пример выше чем Вас не устроил? У веб-разработки, знаете ли, есть такая специфика, как ОЧЕНЬ большой разброс в производительности и прочих возможностях сред исполнения. Если Вы с подобными задачами не сталкивались, это не значит, что их нет.

Нет, с WebGL я дела не имел, но писал достаточно сложные шейдеры на GLSL. Да, замерял время рендера и потребляемые ресурсы, но только в отладочной версии. В релизе это все вырезалось на уровне препроцессора C.

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

Конечно, куда нам, веб-макакам до С-господина… Мы ведь можем тоже отдельный раздел с настройками уровня графики запилить, верно? Хотя стоп, а откуда берутся "рекомендованные настройки" в играх?

куда нам, веб-макакам до С-господина…
Прошу прощения, если это показалось вам слишком грубым, но я только имел ввиду, что за пределами веба зоопарки бывают гораздо шире. Кроме того, я думаю, вы не станете спорить с тем, что веб-приложения — это нечто относительно новое по сравнению с историей разработки «традиционного» software? И «C-господа» уже успели дофига раз «отстрелить себе ногу», «наступить на грабли» и споткнуться «о подводные камни», чтобы вырабатать некие правила, которым потом можно будет научить «веб-макак».

«Рекомендованные настройки» берутся исходя из статистики + таки да, возможно, существуют специальные сборки с бенчмарками, которые раздаются части пользователей за какие-нибудь плюшки. Но вы можете себе представить, например, GTA V, отправляющую разработчикам графики FPS на протяжении всей игры? Я — нет. Модель и производитель видеокарты, версия операционной системы, установленные драйвера, размер памяти — это еще куда ни шло, но FPS точно не отправляется.

Но никто не говорит о отправлении, мы можем просто присваивать индекс производительности на старте приложения и включать/выключать какие-то функции в зависимости от него? Бенчмарк на этом этапе умирает и больше никому не мешает, все остальные манипуляции в коде — просто экстраполяция стартового теста на основе работы уже с профайлерами на тестовом стенде. В том то и дело, что в JS нет доступа к свойствам системы и определить возможности клиента даже приблизительно трудно. Максимум — по типу браузера. И, как я уже сказал, вне веб — адаптация к производительности клиента — вполне нормальная практика, иначе все играли бы только в Супер Марио...

на старте приложения
Вот это, кстати, уже нормальный кейс. Я бы сделал так: на самый первый запуск, когда еще у пользователя не закешированы картинки, скрипты, стили и т.д., показывается экран «Пожалуйста, подождите...» и параллельно выполняется бенчмарк (получается, что он должен грузиться у вас первым, до всех остальных ресурсов). Результат сохраняется в какой-нибудь localStorage, и при следующей загрузке уже ничего не считается. В таком случае да, согласен, можно попробовать.
Это интересный вариант. Но это же надо, чем то занять пользователя, пока бенчмарк издевается над его браузером. :)
Повторил ваш опыт, с множеством вкладок и открытым стендом. Увеличения нагрузки CPU не наблюдаю.
… полностью вырезаем все свои тесты и отдаем пользователю нормальную и быструю программу


Как вы определите, что ваша программа быстрая во всех случаях? Для конкретной машины, пускай даже 5 машин, на которых вы сможете протестить программу — да. А в остальных случая вы уверены?

Но вот пользователям генерировать эти отчеты нет ну никакого смысла...

Я ничего такого и не предлагаю, я просто хочу иметь некую метрику, в зависите от которой, я бы мог так или иначе адаптировать интерфейс.
Как вы определите, что ваша программа быстрая во всех случаях? Для конкретной машины, пускай даже 5 машин, на которых вы сможете протестить программу — да. А в остальных случая вы уверены?
Нет, я в этом не уверен. Но у меня есть статистика по используемым машинам, и я могу запустить виртуалки со всеми самыми распространенными конфигурациями. В автоматическом режиме код будет оттестирован, будут собраны отчеты, я их изучу и сделаю выводы.

Думаю, что вам тоже нужно идти в этом направлении:

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

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


О чем и речь, это каждому разработчику/группе разработчиков нужен такой стенд. И для чего, а для того чтобы просто узнать как исполняет код браузер. А не проще было бы, если бы разработчики браузеров, предоставляли подобную информацию о своих детищах. И не надо было сотен тысяч виртуалок.

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

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

Для каждой версии браузера/движка, для каждой операционной системы и конфигурации железа оптимальный таймаут будет разный.

Это теперь к кроссбраузерности добавится кросспроизводительность? Ну, спасибо!
Как раз недавно очень печалился отсутствием возможности приблизительно узнать производительность клиента и при необходимости отключить тормозные и бесполезные «красивости», либо заменить их на менее прожорливые.
Выжать 60 fps на любом хламе, снижая качество — не такая сложная задача. Бывает хуже. У гипотетического Пети — метросексуальный сони, тонкая машинка, и вот я имею на ней 60 fps, но Петя недоволен — греется у него, видите ли.
Я вовсе, не ставил перед собой задачи в 60 FPS. Иначе я вовсе не использовал бы анимацию и минимум JS кода. Задача состояла в притормаживании слишком «прожорливого» кода, чтобы у пользователя оставался запас на скролл и тыкания мышкой.

Зачем такие сложности с двумя счётчиками? Достаточно иметь массив из 60 чисел, указатель на последний замер и на каждый кадр, смещать указатель, записывать прошедшее в последнего замера время в массив и когда надо — просто разделить 60000 на сумму всех чисел, получив фпс.

Судя по описанию, у вас то, как раз, позаковыристее получается — массивы, указатели :) Ни могли бы показать реализацию в коде.
И что такое 60000? Вы предлагаете среднее за минуту? Я писал, что получать метрику даже 1 раз в секунду слишком медленно.
Спасибо, отличный вариант! Буфер и указатель — супер!
Only those users with full accounts are able to leave comments. Log in, please.