QRusty: QR Codes with precompiled Rust

Hi everyone, I’d like to introduce a library I made for generating QR Codes and address some of the performance gains and some of the drawbacks.

github: GitHub - nbw/qrusty: Elixir QR Code library that leverages precompiled Rust · GitHub

Why use QRusty instead of …?

I think the only real benefit of QRusty is performance. Libraries like EQRCode or QRCode have a wider range of features (color, shapes, etc), plus they’re 100% written in Elixir. I’ve used EQRCode on many projects myself.

QRusty does support the JPG format, which EQRCode doesn’t, but that’s a perk really.

QRCode is supports SVG out of the box. Other formats (PNG, JPG, etc) require external image processing libraries.

Why make this library?

@philss published Rustler precompiled recently which in my opinion makes using Rust for libraries a real option (check out the blog post and the Thinking Elixir episode). I wanted to see what kinds of performance gains could be achieved for simply tasks like generating QR Codes (markdown parsing could be another one, etc).

I’m not a Rust developer. This was also a chance for me to learn Rust and write something for the first time that’s actually useful for me.

What were the performance gains [updated with QRCode]

Compared to EQRCode?

It varies by format and by image size but:

• SVG: ≈ 42x faster
• PNG: ≈ 7x - 27x faster (7x: 500 pixels wide; 27x 100 pixels wide)

I’ve summarised the gains here in the README and also added the raw benchee output here.

It’s worth saying that generating a single QR code is too fast to accurately measure, so the benchmarks are actually testing the time to generate 100 codes.

Why does the PNG performance gain get worse by image size?

You’ll notice that the performance varies between 7x - 27x depending on the image size. I suspect this is because the Rust code deals with the image pixel by pixel (writes each pixel to a buffer).

On the other hand, EQRCode stores a matrix of squares and draws those squares instead of pixel by pixel. Basically, EQRCode is more efficient in that regard and its performance doesn’t vary too much by image size. I haven’t read the code in depth, but you can see mentions of a pixel size and matrix in the png encoder.

Could this gap be fixed or improved? Maybe. I’d be happy to know if there’s a better way than writing to to a Vector buffer when creating generating the file and converting it to a binary.

Compared to QRCode?

• SVG: ≈ 11.8x faster

Are you using it in production?

Yes, we use it on our staging Fly.io environment. Will be deploying to Gigalixir later this week.

Any tips for others using precompiled Rust in a project?

• if you’re running benchmarks locally with a locally compiled rust binary, make sure to enable release mode
• getting the release flow of generating and publishing the Rust binaries as part of a hex package takes a bit of getting used to. Read the documentation a few times and don’t expect to get it right the first time. As @wojtekmach pointed out in this thread you can unpublish a hex release within an hour. There are also handy hex commands to check if the right files are included before publishing

Potential drawbacks of using Rust

It’s in Rust (duh)

The biggest and most obvious one is that it’s not written in Elixir. EQRCode and QRCode are 100% written in Elixir so they’re much easier to read through and maintain. Unless you’re a Rust developer (and I’m not) then it makes it difficult to track down bugs and add features depending on your background.

For my own clarity I included a few rules in the README about using Rust:

• The Rust layer should be as thin as possible
• The Rust layer should not deal with errors caused by human input (ex: invalid input args). Deal with interface errors in Elixir as much as possible
• Default values, etc. should all be handled on the Elixir side

Basically, the end user is an Elixir developer, so keep as much code as possible in Elixir for readability. Leverage Rust only for its performance benefits/access to system level libraries, etc.

Library dependencies

The other issue is that the code is very reliant on whatever existing Rust libraries are available. In the case of QRusty, I had to use a fork of qrcode that supports image v0.24. That’s not my favourite position to be in.

Known issues

• There’s an issue with the width/height of the generated qr code. Seems like the generated qr code code isn’t exactly the specified width/height, but instead the closest size that fits all the qrcode data. will look into it later (issue)

Thank you if you made this far . Let me know what you think and where things could be improved.