WebAssembly: решение проблем с производительностью в Интернете

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

Традиционный JavaScript имеет ограничения производительности из-за того, как движок обрабатывает язык. Интерпретированный (или даже JIT-скомпилированный) язык, который отображается как часть страницы, может получить только очень многое — даже от самого мощного оборудования.

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

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

У меня следующие вопросы: заменяет ли WebAssembly старый добрый традиционный JavaScript? Если нет, то стоит ли инвестировать в изучение WebAssembly?

Что такое WebAssembly?

WebAssembly — это другой тип кода, который можно отправить в браузер. Это в байт-коде , формат означает, что он поставляется на языке ассемблера низкого уровня к тому времени, когда он достигает браузера. Байт-код не предназначен для написания от руки, но может быть скомпилирован из любого языка программирования, такого как C ++ или Rust. Затем браузер может взять любой код WebAssembly, загрузить его как собственный код и добиться высокой производительности.

Вы можете думать об этом байт-коде WebAssembly как о модуле: браузер может извлечь модуль, загрузить и выполнить его. Каждый модуль WebAssembly имеет возможности импорта и экспорта, которые во многом похожи на объекты JavaScript. Модуль WebAssembly действует во многом как любой другой код JavaScript, за исключением того факта, что он работает с почти родной скоростью. С точки зрения программиста, вы можете работать с модулями WebAssembly так же, как вы работаете с текущими объектами JavaScript. Это означает, что то, что вы уже знаете о JavaScript и Интернете, переносится и в программирование WebAssembly.

Инструмент WebAssembly часто состоит из компилятора C ++. В настоящее время существует множество инструментов для разработки, но Emscripten достиг зрелости. Этот инструмент компилирует код C ++ в модуль WebAssembly и создает совместимые со стандартами модули, которые могут работать где угодно. Скомпилированный вывод будет иметь расширение файла WASM, чтобы указать, что это модуль WebAssembly.

Одним из преимуществ WebAssembly является то, что у вас все те же заголовки кэширования HTTP, когда вы выбираете модули. Кроме того, вы можете кэшировать модули WASM, используя IndexedDB, или вы можете кэшировать модули, используя хранилище сеансов . Стратегия кэширования вращается вокруг кэширования запросов API выборки и позволяет избежать еще одного запроса, сохраняя локальную копию. Поскольку модули WebAssembly имеют формат байт-кода, вы можете рассматривать модуль как байтовый массив и хранить его локально.

Теперь, когда мы знаем, что такое WebAssembly, каковы некоторые из его ограничений?

Известные ограничения

JavaScript работает в среде, отличной от любой типичной программы на C ++. Следовательно, ограничения включают то, что нативные API могут делать в среде браузера.

Сетевые функции должны быть асинхронными и неблокирующими операциями. Все базовые сетевые функции JavaScript являются асинхронными в веб-API браузера. WebAssembly, однако, не получает выгоды от асинхронных операций ввода-вывода. Операция ввода-вывода должна ожидать ответа сети, что делает практически все прирост производительности почти невидимым.

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

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

 <p>Add result: <span id="addResult"></span></p> <p>Simple result: <span id="simpleResult"></span></p> 

 (module (func $add (param $lhs i32) (param $rhs i32) (result i32) get_local $lhs get_local $rhs i32.add) (export "add" (func $add))) 

 // URL to the WASM module const WASM_ADD_MODULE = 'https://myhost.com/add.wasm'; fetch(WASM_ADD_MODULE) .then(response => response.arrayBuffer()) .then(bytes => WebAssembly.instantiate(bytes)) .then(result => document.getElementById('addResult').innerHTML = result.instance.exports.add(1, 5)); 

 function 0() { [native code] } 

 (module (func $i (import "imports" "imported_func") (param i32)) (func (export "exported_func") i32.const 42 call $i)) 

 const WASM_SIMPLE_MODULE = 'https://myhost.com/simple.wasm'; const simpleFn = (arg) => document.getElementById('simpleResult').innerHTML = arg; const importSimpleObj = {imports: {imported_func: simpleFn}}; fetch(WASM_SIMPLE_MODULE) .then(response => response.arrayBuffer()) .then(bytes => WebAssembly.instantiate(bytes, importSimpleObj)) .then(result => result.instance.exports.exported_func());