Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upVariable length encoding for enum discriminants #157
Comments
|
Regarding backward compatibility - I think it would be sufficient to provide an external |
|
IMHO there's little to no benefit in creating yet another varint variant. Most will fit 0-127 in a single byte and they could be just reused for sequences/map/string lengths. |
|
Fair enough, let's do that. |
|
LEB128 is a pretty nice format (used in the DWARF format I think) that has a solid Rust crate. |
|
I filed #182 to provide this in an opt-in way for integer types as well. |
|
Is there consensus on making this change? I just ran into this, and I'd rather have bincode do all the work than manually serialize my enum's tag to save 3 bytes per value. |
|
It might be nice to consider (benchmark) PrefixVarint in addition to LEB128. |
|
Has there been any plans about implementing this? I am really interested in this, as it could even further optimize my use-cases. Actually I've been playing around replacing the variant-index with a le-prefix-varint: master...cynecx:prefix-varint (The code is really just hacky, I was confused by all the serde api stuff which I am not familiar with). |
|
@maciejhirsz That sounds like a useful path forward. We would be willing to merge that pull request. |
|
I think #294 could serve as a reasonable template for this. |
|
Closing in favor of #319 |
I think the majority of enum discriminants are less than 128. A very simple variable length encoding like encode <128 as one byte and >=128 as four bytes would address most concerns from people who are astonished that Bincode encodes their 2-variant enum with
[0x00, 0x00, 0x00, 0x00]and[0x00, 0x00, 0x00, 0x01]tags.