Развлекаюсь, вжимая игру на WebAssembly в одно сообщение мессенджера

[pvvv]

>Хорошо сжимаемые ресурсы (HTML, JS) разумно встраивать в WASM при использовании gzip + DecompressionStream.

lzma1 декодер - 1.5кБ минифицированного JS, а жмёт он получше gz. Для 4КБ не поможет конечно, но на размерах в пару десятков КБ может уже оказаться лучше gz, даже не смотря на то что надо ещё и декодер с собой таскать.

[GuestOne]

Да, тут приходится сравнивать размер декодера против размера сэкономленного места. Если игнорировать кроссбраузерность, то DecompressionStream умеет brotli.

Ну и можно ещё сам алгоритм распаковки в WASM скомпилировать, но вряд ли оно побьёт gzip, который браузер даёт практически бесплатно.

[pvvv]

microlzma собранный в wasm получается по размеру больше чем он же на JS :( + 25% от base64 + ещё несколько сотен байт JS обёртки для вызова.

хотя руками сильно оптимизированный под x64 асм этот декодер в 500байт влезает.

[GuestOne]

Это после wasm-opt и gzip? Где посмотреть исходный код?

[pvvv]

c wasm-opt но без gzip, c gzip может и не так плохо, но на паре кБ много насжимать не получится + base64, да и js тоже после минификации ещё и через gzip пропустить можно.

https://github.com/ilyakurdyukov/micro-lzmadec

https://github.com/pavel212/micro-lzmadec-js

[GuestOne]

Да, если не заморачиваться и пройтись теми же инструментами, то выходит ± так же как JS-версия:

7644 lzmadec_lib.c
1510 lzmadec.min.js
2939 lzmadec.wasm
1490 lzmadec.wasm.gz

Наверно, можно преисполниться и написать напрямую на WASM-овских S-выражениях, как вот этот уважаемый человек: https://habr.com/ru/articles/901976/, но я пока не готов :)

[pvvv]

1510 lzmadec.min.js
904  lzmadec.min.js.gz
1208 lzmadec.min.js.gz.b64

но всякие дополнительные eval Blob.stream().pipeThrough(new DecompressionStream("gzip")).getReader().read().then atob(...) эту разницу почти нивелируют