Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I believe the difference is that the JS version specifies compression strategy 3 (Z_RLE)[0][1], whereas the Rust crate is using the default compression strategy[2]. Both otherwise use the same underlying compression library (deflate aka zlib) and the same compression level (9).

[0]: https://github.com/pretzelhammer/using-rust-in-non-rust-serv...

[1]: https://zlib.net/manual.html#Advanced:~:text=The%20strategy%...

[2]: https://github.com/rust-lang/flate2-rs/blob/1a28821dc116dac1...

Edit: Nevermind. If you look at the actual generated files, they're 594 and 577 bytes respectively. This is mostly HTTP headers.

[3]: https://github.com/pretzelhammer/rust-blog/blob/master/asset...

[4]: https://github.com/pretzelhammer/rust-blog/blob/master/asset...



Author here. I believe I generated both of those images using the Rust lib, they shouldn't be used for comparing the compression performance of the JS lib vs the Rust lib.


Interesting, but neither lines up with the size from the benchmarking? You would expect the Rust one to match?


Here's the list of my benchmark targets: https://github.com/pretzelhammer/using-rust-in-non-rust-serv...

Vegeta, the tool I used for benchmarking, iterates through all those targets round-robin style while attacking the server and then averages the results when reporting the average response size in bytes (and it only measures the size of the response body, it doesn't include other things like headers).

Even using the same library and same compression algorithm not all 200px by 200px QR code PNGs will compress to the same size. How well they can be compressed depends a lot on the encoded piece of text as that determines the visual complexity of the generated QR code.


I see. I misread the article as implying that only the specified URLs were being benchmarked.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: