-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Include benchmarks #14
Comments
@RReverser thanks for the feedback I agree that claims should be backed and there should be an extensive benchmarking for Existing DemoHowever, there is a demo/benchmark you can test here - https://wasm-flate.s3-website-us-east-1.amazonaws.com/ While this is not comprehensive (not mentioned in the docs) but apparent in some testing - Convos about passing data between JS and WASMWebAssembly/design#1231 I've been trying to keep up with WS developments so As those critical WebAssembly design features get sorted out - So, it's hard to know if Any ideas on the zero-copy issue, or your experiences with |
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. |
updated the description 👍 |
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 :) |
@RReverser @drbh The tweet button also has the similar text that needs to be updated. |
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 nativeCompressionStream
to the list of implementations in https://github.com/nodeca/pako/tree/master/benchmark/implementations.The text was updated successfully, but these errors were encountered: