Хабрахабр

Как мы внедряли WebAssembly в Яндекс.Картах и почему оставили JavaScript

Меня зовут Валерий Шавель, я из команды разработки векторного движка Яндекс.Карт. Недавно мы внедряли в движок технологию WebAssembly. Ниже я расскажу, почему мы её выбрали, какие результаты получили и как вы можете использовать эту технологию в своём проекте.

Фактически тайл — индексированная область карты.
В Яндекс.Картах векторная карта состоит из кусочков, называемых тайлами. Тайлы приходят с сервера на клиент закодированными, и перед отображением необходимо обработать все примитивы. Карта векторная, поэтому в каждом тайле содержится немало геометрических примитивов. Тайл может содержать больше 2 тысяч ломаных и многоугольников. Иногда это занимает существенное время.

Если тайл не будет подготовлен достаточно быстро — то и пользователь увидит его поздно, и следующие тайлы задержатся в очереди. При обработке примитивов важнее всего производительность. Чтобы ускорить обработку, мы решили попробовать относительно новую технологию WebAssembly (Wasm).

Использование WebAssembly в картах

Сейчас бо́льшая часть обработки примитивов происходит в фоновом потоке (Web Worker), который живёт отдельной жизнью. Это сделано для того, чтобы максимально разгрузить главный поток. Таким образом, когда код для показа карты встраивается на страницу сервиса, который может сам добавлять существенную нагрузку, тормозов будет меньше. Минус в том, что нужно правильно настраивать обмен сообщениями между главным потоком и Web Worker’ом.

Часть обработки, происходящая в фоновом потоке, состоит, по сути, из двух шагов:

  1. Декодируется формат protobuf, который приходит с сервера.
  2. Геометрии генерируются и записываются в буферы.

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

Очевидно, что во время второго шага происходит немало манипуляций с памятью и математических расчётов, потому что для правильного рендеринга примитивов нужно много информации о каждой вершине примитива:

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

Также Wasm кое в чём очевидно хуже, чем TypeScript:

  1. Нужно инициализировать специальный модуль с необходимыми нам функциями. Это может привести к задержке перед началом работы этой функциональности.
  2. Намного больший, чем в TS’е, размер исходного кода при компиляции Wasm’а.
  3. Разработчикам приходится поддерживать альтернативный вариант исполнения кода, который к тому же написан на нетипичном для фронтенда языке.

Однако, несмотря на всё это, мы рискнули переписать часть своего кода с использованием Wasm’а.

Общая информация о WebAssembly

Часто такой заранее скомпилированный код оказывается быстрее классического JavaScript’a. Wasm — это бинарный формат; можно скомпилировать в него разные языки, а затем запустить код в браузере. Код в формате WebAssembly не имеет доступа к DOM-элементам страницы и, как правило, применяется для выполнения на клиенте трудоёмких вычислительных задач.

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

После его установки и добавления в проект на C++, чтобы получить модуль, нужно написать главный файл проекта определённым образом. Для компиляции C++ в WebAssembly мы применяли emscripten. Например, он может выглядеть вот так:

#include <emscripten/bind.h>
#include <emscripten.h>
#include <math.h> struct Point { double x; double y;
}; double sqr(double x) { return x * x;
} EMSCRIPTEN_BINDINGS(my_value_example) ));
}

Далее я опишу, как вы можете использовать этот код в своём проекте на TypeScript.

В коде мы определяем структуру Point и ставим ей в соответствие интерфейс Point в TypeScript, в котором будет два поля — x и y, они соответствуют полям структуры.

Тогда в TypeScript ему будет соответствовать интерфейс с нужными функциями. Далее, если мы захотим вернуть стандартный контейнер vector из C++ в TypeScript, то понадобится зарегистрировать его для типа Point.

И наконец, в коде показано, как зарегистрировать свою функцию, чтобы вызвать её из TypeScript по соответствующему имени.

Теперь мы можем для произвольного модуля emscripten написать общий файл d.ts, в котором заранее определены полезные функции и типы: Скомпилируйте файл с помощью emscripten и добавьте получившийся модуль в свой проект на TypeScript’е.

declare module "emscripten_module" { interface EmscriptenModule { readonly wasmMemory: WebAssembly.Memory; readonly HEAPU8: Uint8Array; readonly HEAPF64: Float64Array; locateFile: (path: string) => string; onRuntimeInitialized: () => void; _malloc: (size: size_t) => uintptr_t; _free: (addr: size_t) => uintptr_t; } export default EmscriptenModule; export type uintptr_t = number; export type size_t = number;
}

И можем написать файл d.ts для нашего модуля:

declare module "emscripten_point" { import EmscriptenModule, {uintptr_t, size_t} from 'emscripten_module'; interface NativeObject { delete: () => void; } interface Vector<T> extends NativeObject { get(index: number): T; size(): number; } interface Point { readonly x: number; readonly y: number; } interface PointModule extends EmscriptenModule { distance: (point1: Point, point2: Point) => number; } type PointModuleUninitialized = Partial<PointModule>; export default function createModuleApi(Module: Partial<PointModule>): PointModule;
}

Теперь мы можем написать функцию, которая создаст Promise на инициализацию модуля, и воспользоваться ей:

import EmscriptenModule from 'emscripten_module';
import createPointModuleApi, {PointModule} from 'emscripten_point';
import * as pointModule from 'emscripten_point.wasm'; /** * Promisifies initialization of emscripten module. * * @param moduleUrl URL to wasm file, it could be encoded data URL. * @param moduleInitializer Escripten module factory, * see https://emscripten.org/docs/compiling/WebAssembly.html#compiler-output. */
export default function initEmscriptenModule<ModuleT extends EmscriptenModule>( moduleUrl: string, moduleInitializer: (module: Partial<EmscriptenModule>) => ModuleT
): Promise<ModuleT> { return new Promise((resolve) => { const module = moduleInitializer({ locateFile: () => moduleUrl, onRuntimeInitialized: function (): void { // module itself is thenable, to prevent infinite promise resolution delete (<any>module).then; resolve(module); } }); });
} const initialization = initEmscriptenModule( 'data:application/wasm;base64,' + pointModule, createPointModuleApi
);

Теперь по этому Promise мы получаем наш модуль вместе с функцией distance.

Поэтому необходимо писать тесты и запускать на них код как обычный C++, тогда у вас будет возможность удобной отладки. К сожалению, отлаживать Wasm-код построчно в браузере нельзя. Тем не менее даже в браузере у вас есть доступ к стандартному потоку cout, который выведет всё в консоль браузера.

По этой ссылке доступен проект-пример из статьи, там вы можете посмотреть настройку webpack.config и CMakeLists.

Результаты

Итак, мы переписали часть своего кода и запустили эксперимент, чтобы рассмотреть парсинг ломаных и многоугольников. На диаграмме продемонстрированы медианные результаты по одному тайлу для Wasm’а и JavaScript’а:

В итоге мы получили такие относительные коэффициенты по каждой метрике:

Если же смотреть общее время парсинга, то здесь разница тоже значительная, однако она всё-таки немного меньше. Как видно по чистому времени парсинга примитивов и времени декодирования тайла, Wasm быстрее более чем в четыре раза. Также стоит отметить, что на первых тайлах общий выигрыш очень высок (на первых десяти — больше чем в пять раз). Это связано с затратами на то, чтобы передать данные в Wasm и забрать результат. Однако потом относительный коэффициент уменьшается примерно до трёх.

Конечно, эта разница не так велика, как предыдущие, однако нужно понимать, что парсинг ломаных и многоугольников — это далеко не вся обработка тайла. В итоге всё это вместе помогло на 20–25% снизить время обработки одного тайла в фоновом потоке.

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

Сжатый gzip’ом минифицированный код всего векторного движка карты без Wasm’а — 85 КБ, с Wasm’ом — 191 КБ. Ещё одна отрицательная сторона — размер файла с исходным кодом. Более того, для декодирования protobuf’а пришлось выбрать реализацию библиотеки на чистом C, с реализацией на C++ размер был ещё больше. При этом в Wasm’е реализован только парсинг ломаных и прямоугольников, а не всех примитивов, которые могут быть в тайле. Кроме того, при такой замене мы теряем в производительности. Эту разницу можно несколько уменьшить, если при компиляции C++ использовать флаг компилятора -Oz вместо -O3, но она по-прежнему существенна.

Wasm хуже только на медленных устройствах, и разница — менее 2%. Тем не менее размер исходника на скорость инициализации карты повлиял незначительно. Это связано с бо́льшим выигрышем на первых обработанных тайлах, пока JS ещё не оптимизирован. А вот изначальный видимый набор векторных тайлов в реализации с Wasm’ом был показан пользователям немного быстрее, чем с JS’ной реализацией.

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

Это связано с тем, что выигрыш в парсинге не так велик на общем фоне, и с тем, что в Wasm’е реализован парсинг только некоторых типов примитивов. В наших картах сейчас работает обычный JavaScript. Ещё один весомый аргумент против — сложность сборки и отладки: поддерживать проект на двух языках имеет смысл только тогда, когда выигрыш в производительности того стоит. Если это изменится — возможно, мы станем применять Wasm.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть