[voiper1]

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]

> 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" for the first, "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).

[loeg]

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...

[pretzelhammer]

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]

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

[pretzelhammer]

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.

[loeg]

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

[xnorswap]

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]

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

[pretzelhammer]

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]

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