Comments 38
В Chrome по-любому есть что-то аналогичное.
Затем, что мы не видим этих графиков из JS?
Вы пункт "Бла бла бла" не читали? Для реализации чего-то типа graceful degradation в JS-рантайме?
К примеру, я сейчас делаю редактор списков который в реальном времени добавляет/убирает элементы, которые могут содержать пользовательские данные со сложной структурой. При превышении определенного порога по количеству элементов — редактор переключается в упрощенный режим, чтобы браузер продолжал его рендерить без тормозов. Мне вполне бы пригодился инструмент для автоматического определения этого порога.
Прошу отметить, что считалка не моя, я говорю о проблеме безотносительно данного конкретного решения, в котором тоже вижу некоторые недостатки. Вы знаете как сделать лучше?
… в котором тоже вижу некоторые недостатки
Видите — пишите что не так, оч интересно глянуть как вы считаете.
Меня смущают множественные асинхронные вызовы, которые будут смешиваться в очереди с тем, что может нагенерить само приложение. Мы не можем достоверно узнать время начала и конца простоя, чтобы запустить тест в фоне в этот момент.
… которые будут смешиваться в очереди с тем,...
Для этого у меня везде и используется requestAnimationFrame, который не запускает функцию здесь и сейчас, а группирует несколько вызовов в одну пачку и выполняет, выбирая оптимальный момент для запуска.
Ок, а что происходит с очередью вызовов не связанных с рендером DOM? В нее точно так-же встраиваются колбэки из requestAnimationFrame, как и из setTimeout/setInterval ведь? И если никакой анимации нет, а есть, к примеру, парсинг JSON — вызовы бенчмарка замедляют весь остальной код?
А вот для простых страничек — да, пускай там будет производительность хоть 100500 кадров в секунду, вопрос: откуда там вообще берутся эти кадры, если страница статична, ее можно было просто один раз записать в видеопамять, а потом бы уже видеокарта ее аппаратно блендила с остальными окнами.
Предлагаю завернуть бенчмарк в веб-воркер, можно будет по настоящему асинхронно тестить производительность без каких-либо блокировок и аффектов в приложении.
какой смысл в это время что-то анимировать
А анимировать не обязательно, нагрузку и перерисовку может создать сам пользователь, масштабируя окно или, к примеру, редактируя contenteditable.
Так ваша считалка и будет составлять основную нагрузку.
Какой именно участок кода, по вашему мнению будет давать нагрузку? Если жмакните по ссылке на 'стенд', то увидите, что при запущенном счетчике и вашем бездействие, FPS будет 60. Так что о какой нагрузке речь, я не понимаю.
А зачем на них «смотреть» из JS?
Вот, в потом то и печаль, что разработчики даже не понимают зачем это нужно. Используя штатные средства, вы можете оценить производительность на конкретной машине с конкретной конфигурацией и конкретным js-движком. А что делать с остальными миллионами пользователей с их разнообразием железа, ОС и д.т.? Есть два варианта либо вы зайдете к каждому и запустите на его машине средства разработки в браузере, либо всем пользователям нужно иметь такую же конфигурацию аппаратно-программных средств как у вас.
Если жмакните по ссылке на 'стенд', то увидите, что при запущенном счетчике и вашем бездействие, FPS будет 60Какая мне разница, какой у вас FPS? Открываю пустую страницу, Firefox потребляет 13% времени ЦП (у меня сейчас открыто много вкладок). Открываю ваш «стенд», потребление сразу растет до 20%, а если поводить над окном мышкой, то даже 30%.
Вот, в потом то и печаль, что разработчики даже не понимают зачем это нужно.Поверьте мне, я прекрасно понимаю, как оптимизируются программы, учитывая, что мне иногда даже приходится заглядывать в сгенерированный компилятором машинный код.
Профайлинг, бенчмаркинг, etc. — это все хорошо, но только для отладочной версии. Попробовали разные алгоритмы, нашли «узкие места» — поздравляю, теперь полностью вырезаем все свои тесты и отдаем пользователю нормальную и быструю программу. Возьмите, для примера, тот же Firefox и запустите его в отладочном режиме. Производительность упадет значительно, потому что это помогает разработчикам понять, что и где еще можно ускорить. Но вот пользователям генерировать эти отчеты нет ну никакого смысла (и посылать эти отчеты разработчикам тоже).
Поверьте мне, я прекрасно понимаю
Я не верю. Вы с WebGL дело имели? А с Web VR? А мой пример выше чем Вас не устроил? У веб-разработки, знаете ли, есть такая специфика, как ОЧЕНЬ большой разброс в производительности и прочих возможностях сред исполнения. Если Вы с подобными задачами не сталкивались, это не значит, что их нет.
В общем, приложение ваше, пользователи тоже ваши, хотите принудительно запускать у каждого по бенчмарку — пожалуйста, ваше право. Да хоть майньте Биткоины, главное же чтобы FPS не сильно падал.
Конечно, куда нам, веб-макакам до С-господина… Мы ведь можем тоже отдельный раздел с настройками уровня графики запилить, верно? Хотя стоп, а откуда берутся "рекомендованные настройки" в играх?
куда нам, веб-макакам до С-господина…Прошу прощения, если это показалось вам слишком грубым, но я только имел ввиду, что за пределами веба зоопарки бывают гораздо шире. Кроме того, я думаю, вы не станете спорить с тем, что веб-приложения — это нечто относительно новое по сравнению с историей разработки «традиционного» software? И «C-господа» уже успели дофига раз «отстрелить себе ногу», «наступить на грабли» и споткнуться «о подводные камни», чтобы вырабатать некие правила, которым потом можно будет научить «веб-макак».
«Рекомендованные настройки» берутся исходя из статистики + таки да, возможно, существуют специальные сборки с бенчмарками, которые раздаются части пользователей за какие-нибудь плюшки. Но вы можете себе представить, например, GTA V, отправляющую разработчикам графики FPS на протяжении всей игры? Я — нет. Модель и производитель видеокарты, версия операционной системы, установленные драйвера, размер памяти — это еще куда ни шло, но FPS точно не отправляется.
Но никто не говорит о отправлении, мы можем просто присваивать индекс производительности на старте приложения и включать/выключать какие-то функции в зависимости от него? Бенчмарк на этом этапе умирает и больше никому не мешает, все остальные манипуляции в коде — просто экстраполяция стартового теста на основе работы уже с профайлерами на тестовом стенде. В том то и дело, что в JS нет доступа к свойствам системы и определить возможности клиента даже приблизительно трудно. Максимум — по типу браузера. И, как я уже сказал, вне веб — адаптация к производительности клиента — вполне нормальная практика, иначе все играли бы только в Супер Марио...
на старте приложенияВот это, кстати, уже нормальный кейс. Я бы сделал так: на самый первый запуск, когда еще у пользователя не закешированы картинки, скрипты, стили и т.д., показывается экран «Пожалуйста, подождите...» и параллельно выполняется бенчмарк (получается, что он должен грузиться у вас первым, до всех остальных ресурсов). Результат сохраняется в какой-нибудь localStorage, и при следующей загрузке уже ничего не считается. В таком случае да, согласен, можно попробовать.
… полностью вырезаем все свои тесты и отдаем пользователю нормальную и быструю программу
Как вы определите, что ваша программа быстрая во всех случаях? Для конкретной машины, пускай даже 5 машин, на которых вы сможете протестить программу — да. А в остальных случая вы уверены?
Но вот пользователям генерировать эти отчеты нет ну никакого смысла...
Я ничего такого и не предлагаю, я просто хочу иметь некую метрику, в зависите от которой, я бы мог так или иначе адаптировать интерфейс.
Как вы определите, что ваша программа быстрая во всех случаях? Для конкретной машины, пускай даже 5 машин, на которых вы сможете протестить программу — да. А в остальных случая вы уверены?Нет, я в этом не уверен. Но у меня есть статистика по используемым машинам, и я могу запустить виртуалки со всеми самыми распространенными конфигурациями. В автоматическом режиме код будет оттестирован, будут собраны отчеты, я их изучу и сделаю выводы.
Думаю, что вам тоже нужно идти в этом направлении:
1. Собрать подробную статистику. Например, для веба можете использовать modernizr, он достаточно хорошо определяет наличие тех или иных фич. По результатам поднимите тестовые окружения по самым распространенным конфигурациям.
2. Для случаев, когда пользователь жалуется на слабую производительность, сделайте возможность запуска своих бенчмарков. Но не суйте их всем подряд, а сделайте какую-нибудь галочку глубоко в настройках.
Но у меня есть статистика по используемым машинам, и я могу запустить виртуалки со всеми самыми распространенными конфигурациями.
О чем и речь, это каждому разработчику/группе разработчиков нужен такой стенд. И для чего, а для того чтобы просто узнать как исполняет код браузер. А не проще было бы, если бы разработчики браузеров, предоставляли подобную информацию о своих детищах. И не надо было сотен тысяч виртуалок.
Для случаев, когда пользователь жалуется на слабую производительность...
Они никому не жалуются, они просто закрывают сайт и ищут альтернативу.
Вы про это? Да это позволяет, примерно оценить работу кода в разных условиях. И если заморочиться и высчитать все возможные случаи относительно вашем машины, то конечно можно получить представление о том как ваш код исполняется на разных машинах. Но вам, тогда необходимо будет выбирать компромиссный вариант, который будет устраивать всех и сразу. А хочется динамически определять возможности клиента и прямо в рантайме оптимизировать исполнение.
Это дает разработчику знание какой синтаксис и API он может использовать.
Для каждой версии браузера/движка, для каждой операционной системы и конфигурации железа оптимальный таймаут будет разный.
Это теперь к кроссбраузерности добавится кросспроизводительность? Ну, спасибо!
Зачем такие сложности с двумя счётчиками? Достаточно иметь массив из 60 чисел, указатель на последний замер и на каждый кадр, смещать указатель, записывать прошедшее в последнего замера время в массив и когда надо — просто разделить 60000 на сумму всех чисел, получив фпс.
FPS и пусть ваш код подождет