3 ms·

Wow, that's an incredible writeup. Super surprised that shelling out was nearly as good any any other method. Why is the average bytes smaller? Shouldn't it b

Wow, that's an incredible writeup. Super surprised that shelling out was nearly as good any any other method. Why is the average bytes smaller? Shouldn't it be the same size file? And if not, it's a different alorithm so not necessarily better?

pixelesque 2y ago
> Why is the average bytes smaller? Shouldn't it be the same size file? The content being encoded in the PNG was different ("https://www.reddit.com/r/rustjerk/top/?t=all https://www.reddit.com/r/rustjerk/top/?t=all" for the first, "https://youtu.be/cE0wfjsybIQ?t=74 https://youtu.be/cE0wfjsybIQ?t=74" for the second example - not sure whether the benchmark used different things?), so I'd expect the PNG buffer pixels to be different between those two images and thus the compressed image size to be a bit different, even if the compression levels of DEFLATE within the PNG were the same).
xnorswap 2y ago
That struck me as odd too. It may be just additional HTTP headers added to the response, but then it's hardly fair to use that as a point of comparison and treat smaller as "better".
- loeg 2y ago
  I think your guess is spot on. The QRcode images themselves are 594 and 577 bytes. The vast majority of the difference must be coming from other factors (HTTP headers). https://news.ycombinator.com/item?id=41973396 https://news.ycombinator.com/item?id=41973396
  - pretzelhammer 2y ago
    Author here. The benchmarking tool I used for measuring response size was vegeta, which ignores HTTP headers in its measurements. I believe the difference in size is indeed in the QR code images themselves.
jyap 2y ago
The article says: Average response size also halved from 1506 bytes to 778 bytes, the compression algo in the Rust library must be better than the one in the JS library
loeg 2y ago
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-servers/blob/main/node/tier-0-no-rust/generate-qr.js#L14 https://github.com/pretzelhammer/using-rust-in-non-rust-serv... [1]: https://zlib.net/manual.html#Advanced:~:text=The%20strategy%20parameter%20is%20used%20to%20tune%20the%20compression%20algorithm https://zlib.net/manual.html#Advanced:~:text=The%20strategy%... [2]: https://github.com/rust-lang/flate2-rs/blob/1a28821dc116dac14178858be056e4a58ef8f501/src/ffi/c.rs#L323 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/assets/rustjerk-subreddit-qr-code.png https://github.com/pretzelhammer/rust-blog/blob/master/asset... [4]: https://github.com/pretzelhammer/rust-blog/blob/master/assets/crab-rave-qr-code.png https://github.com/pretzelhammer/rust-blog/blob/master/asset...
- pretzelhammer 2y ago
  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.
  - loeg 2y ago
    Interesting, but neither lines up with the size from the benchmarking? You would expect the Rust one to match?
    - pretzelhammer 2y ago
      Here's the list of my benchmark targets: https://github.com/pretzelhammer/using-rust-in-non-rust-servers/blob/main/targets.txt 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.

pixelesque 2y ago

> Why is the average bytes smaller? Shouldn't it be the same size file? The content being encoded in the PNG was different ("https://www.reddit.com/r/rustjerk/top/?t=all https://www.reddit.com/r/rustjerk/top/?t=all" for the first, "https://youtu.be/cE0wfjsybIQ?t=74 https://youtu.be/cE0wfjsybIQ?t=74" for the second example - not sure whether the benchmark used different things?), so I'd expect the PNG buffer pixels to be different between those two images and thus the compressed image size to be a bit different, even if the compression levels of DEFLATE within the PNG were the same).

xnorswap 2y ago

That struck me as odd too. It may be just additional HTTP headers added to the response, but then it's hardly fair to use that as a point of comparison and treat smaller as "better".

loeg 2y ago
I think your guess is spot on. The QRcode images themselves are 594 and 577 bytes. The vast majority of the difference must be coming from other factors (HTTP headers). https://news.ycombinator.com/item?id=41973396 https://news.ycombinator.com/item?id=41973396
- pretzelhammer 2y ago
  Author here. The benchmarking tool I used for measuring response size was vegeta, which ignores HTTP headers in its measurements. I believe the difference in size is indeed in the QR code images themselves.

jyap 2y ago

The article says: Average response size also halved from 1506 bytes to 778 bytes, the compression algo in the Rust library must be better than the one in the JS library

loeg 2y ago

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-servers/blob/main/node/tier-0-no-rust/generate-qr.js#L14 https://github.com/pretzelhammer/using-rust-in-non-rust-serv... [1]: https://zlib.net/manual.html#Advanced:~:text=The%20strategy%20parameter%20is%20used%20to%20tune%20the%20compression%20algorithm https://zlib.net/manual.html#Advanced:~:text=The%20strategy%... [2]: https://github.com/rust-lang/flate2-rs/blob/1a28821dc116dac14178858be056e4a58ef8f501/src/ffi/c.rs#L323 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/assets/rustjerk-subreddit-qr-code.png https://github.com/pretzelhammer/rust-blog/blob/master/asset... [4]: https://github.com/pretzelhammer/rust-blog/blob/master/assets/crab-rave-qr-code.png https://github.com/pretzelhammer/rust-blog/blob/master/asset...

pretzelhammer 2y ago
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.
- loeg 2y ago
  Interesting, but neither lines up with the size from the benchmarking? You would expect the Rust one to match?
  - pretzelhammer 2y ago
    Here's the list of my benchmark targets: https://github.com/pretzelhammer/using-rust-in-non-rust-servers/blob/main/targets.txt 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.