Include benchmarks

[RReverser]

This library claims to be the fastest, but doesn't include any benchmarks that could be ran, reproduced by users and compared with other libraries.

Absence of numbers and reproducible benchmarks usually makes such claims in libraries questionable, as they sound like just common marketing phrases.

While I hope it's not the case here, it would still be really helpful if such benchmarks would be included - for example, you could reuse the ones that pako - library you're comparing this one to - already includes, but add yours and native CompressionStream to the list of implementations in https://github.com/nodeca/pako/tree/master/benchmark/implementations.

[drbh]

@RReverser thanks for the feedback

I agree that claims should be backed and there should be an extensive benchmarking for wasm-flate.

Existing Demo

However, there is a demo/benchmark you can test here - http://wasm-flate.s3-website-us-east-1.amazonaws.com/

While this is not comprehensive (not mentioned in the docs) but apparent in some testing - wasm-flate currently has the disadvantage of having no efficient way to do stream compression. This is due to the nature of WebAssembly and the memory format. The current WebAssembly standard (afaik) does not provide a way to zero-copy data from JS to WASM. This limitation impacts how fast wasm-flate can compress large files.

Convos about passing data between JS and WASM

WebAssembly/design#1231
WebAssembly/design#1162

I've been trying to keep up with WS developments so wasm-flate can provide the most effective way to handle stream compression/decompression over larger files.

As those critical WebAssembly design features get sorted out - wasm-flate will be in flux and extensive benchmarking will follow.

So, it's hard to know if wasm-flate will be faster in your use case, but it does execute the core compression algorithms faster and lower overhead way (using wasm). Depending on how large and how frequently you compress data in your app the results will vary.

Any ideas on the zero-copy issue, or your experiences with wasm-flate in your use case?

[RReverser]

Yeah I'm aware of the current limitations of WebAssembly and happy to chat about them separately, but in the context of this issue it's one of the reasons why I'm saying that the repo should include proper benchmarks and numbers that reflect current state of things and prove that this library is the fastest one around.

Otherwise, if under current condition the claim about "fastest compression and decompression in the browser and server" doesn't hold with existing APIs, then I'd suggest it should be removed from description, as in that case it's very misleading.

[drbh]

updated the description 👍

[RReverser]

Thank you for making a responsible decision!

I'd still love to see benchmark numbers out of curiosity and so that library could be more easily improved over time, but it's up to you whether to keep the issue open for tracking that, or to close it for now :)

[vinaydotblog]

@RReverser @drbh The tweet button also has the similar text that needs to be updated.