Благодаря войне браузеров JS-движки основных браузеров внедрили различные технологии оптимизации, а новости о том, что производительность некоторых браузеров время от времени значительно улучшалась, также повысили доверие студентов, изучающих интерфейс. Итак, достиг ли сам язык JS уровня, близкого к нативному?
идеи
Мы знаем, что сегодняшний JavaScript — это, по сути, язык сценариев, даже с введением методов компиляции более высокого уровня, таких как JIT. Не говоря уже о таких языках, как C/C++, которые можно скомпилировать в собственный машинный код, даже по сравнению с Java, использующей байт-код, среда выполнения JavaScript не имеет принципиального преимущества. Так вот вопрос, как?количественноКак насчет разрыва между скоростью JS и родным языком?
Существует множество тестов Todo MVC в области интерфейсных фреймворков, и их сравнение можно просто понять какСравнение производительности реализации одной и той же функции на разных платформах. Хотя это осуществимо и легко поддается количественной оценке, различные реализации кодирования и методы построения могут значительно изменить данные эталонного теста (например, открывать ли плагин оптимизации React и т. д.), а сценарий Todo MVC в основном ограничен добавлением данных, проверка, модификация и удаление. , не является сложным приложением в реальной сцене.
Отметив, что сегодня многие языки программирования уже компилируются в JavaScript, мы выбрали другой подход:Сравните производительность нативных и JavaScript-версий реальных приложений.. А, учитывая, что Web Assembly стала стандартом, у нас есть возможность сравнить производительность нативного кода, WASM и JS, что кажется еще более интересным.
Как выбрать приложение для тестирования? Нам нужны сценарии с интенсивными вычислениями, чтобы выжать производительность во время выполнения, наиболее распространенными из которых являются игры и обработка мультимедиа. Мы выбрали FFmpeg, который является очень старым брендом в области кодирования видео, и протестировали скорость кодирования видео разных версий, встроив его в WASM и JavaScript, чтобы получить эталон сравнения производительности между родным, WASM и JS.
процесс и результаты
Мы хотели сравнить скорость трех сборок FFmpeg при кодировании видео с конфигурацией по умолчанию:
- Родной
- версия JavaScript
- WASM-версия
Входным файлом для теста является JS-версия FFmpeg (то есть библиотека videoconverter.js), которая поставляется сДемонстрационное видео, тестовая платформа — MacBook Pro Beggar Edition 2015 года.
Родной
Версия, установленная с Homebrew:
time ffmpeg -i bigbuckbunny.webm output.mp4
Время, необходимое для транскодирования, равно6sо.
версия JavaScript
videoconverter.jsПоставляется со статической демонстрационной страницей из коробки, где вы можете перекодировать видео. выберитеVideo to .MP4Просто вывод. Время, необходимое для транскодирования, равно140sо.
WASM-версия
WASM-версия FFmpeg не имеет стабильной версии от сообщества, вот ссылкаэтот столбецМетод сборки, после установки Emscripten, скомпилировать FFmpeg из исходников в WASM, получитffmpeg.wasmдля транскодирования.
После компиляции приложения C в WASM мы можем использовать его в Web Worker. Просто передайте исходные аргументы командной строки в другом формате:
ffmpeg({
arguments: [
'-i', '/input/demo.mp4',
'out.mp4'
],
files
}, function (results) {
self.postMessage(results[0].data)
})
Время, необходимое для измерения24sо.
В заключение
Мы наблюдали относительно значительные различия в производительности:
В этом сценарии с интенсивными вычислениями производительность JavaScript1/20вокруг, в то время как производительность WASM может достигать родной1/4Левый и справа (добавлено акцент, это только вывод для этого сценария, не универсальный).
Но эти данные можно использовать только для справки, причина в том, что во всей ссылке еще много неявных ям. Назвать несколько:
- На показатели теста видеокодирования большое влияние оказывают алгоритмы и параметры. Конфигурация по умолчанию, основанная на FFmpeg, может не гарантировать согласованности выполняемых путей кода.
- Компиляция FFmpeg в WASM требует много настроек, таких как отключение встроенного кода сборки, зависящего от платформы, отключение многопоточности и т. д. Это влияет на производительность окончательной сборки.
- WASM часто не может добиться увеличения производительности в несколько раз по сравнению с нативным JS. В некоторых примерах (таких как обработка изображений), которые используют JS для вызова модулей WASM вместо компиляции всего приложения в WASM, накладные расходы на частое копирование данных между WASM и JS очень высоки, и даже производительность WASM может быть не такой хорошей. как JS.
Несмотря на эти отвлекающие факторы, в основном мы можем сказать, что разрыв в производительности между JavaScript и нативным кодом все еще может быть на порядки. Просто в нынешних распространенных сценариях, таких как промежуточный и фоновый, активные страницы и гибрид, нам редко приходится использовать JavaScript для обработки ресурсоемких задач, а стать узким местом всего приложения непросто.
Надеюсь, этот простой тест поможет вам понять, насколько на самом деле медленный JS. Но наша хорошая новость заключается в том, что, с другой точки зрения, JS на мобильных устройствах больше не работает медленнее, чем JS на ПК.эта статья.
Наконец, перечислите соответствующие ресурсы, задействованные в статье: