I've been using bincode a lot over the years, and since it has been discontinued I wanted to find something that I can switch to for new projects with as little friction as possible. The bincode developers themselves recommend three different alternatives, but seem to prefer rkyv -- so I went with that.

Here's what I did not realize (and this is entirely my fault, I have since noticed it is quite clearly stated in many places): bincode actually serializes and deserializes. rkyv, on the "deserializing" side, does not "deserialize" (well, depending on how one defines it) -- it basically treats your type as a "view type" that it places on top of a memory blob. (.. which is why rkyv can be fiendishly fast).

So how hard can this bite you? Well, it depends on how aligned your input buffer is and how aligned your type needs to be.

If you're using some kind of protocol framing library that writes incoming data to a BytesMut, there's a pretty good chance that your data will not be properly aligned for rkyv. While it will go boom (by default), it will give you a pretty good error message telling you why.

There are solutions to this (if you want to use rkyv), for instance:

• Avoid using framing libraries (like tokio-util's Framed) that may not give you aligned data, and instead read the serialized frames yourself into an AlignedVec.
• If you want to use tokio-util's Framed (but can live with copying the data most of the time), you can check the address of the buffer before deserializing, and if it is misaligned, copy the data to an AlignedVec and deserialize it from there.
• BytesMut has a align_to method that looks promising, though I haven't used it yet.

Again, the problems I ran into with rkyv are my fault. It's a really cool library, and I'm going to use it going forward -- but you gotta think about buffer alignment in a way you may not be used to if you've been using bincode.

1 post - 1 participant

Read full topic