2 ms·
IMHO wasting 12.5% of all bits just to store the length appears wasteful to me. The encoding in QUIC[1] that encodes the length in the leading to 2bits. Very fa
by maxmuen 2y ago
IMHO wasting 12.5% of all bits just to store the length appears wasteful to me.
The encoding in QUIC[1] that encodes the length in the leading to 2bits. Very fast to read and write, just one caveat at most 62bits allowed.
[1]: https://www.rfc-editor.org/rfc/rfc9000.html#name-variable-length-integer-enc https://www.rfc-editor.org/rfc/rfc9000.html#name-variable-le...
- Retr0id 2y agoIt depends on your probability distribution of values. Storing the number 100 (decimal) under the QUIC scheme would require 2 bytes, but only 1 byte under either "metric" or "imperial" varints. (same for any value between 64 and 127, I believe (I might be off-by-one there...))
- Retr0id 2y agoWeird, this comment got downvoted, twice. Which led me to believe I might be wrong, but I just double-checked and I'm definitely right. Anyone care to explain?
- Dylan16807 2y agoThe method in the article adds 14% and then rounds up to the nearest byte. On values up to 63/64 bits (depending on implementation) it wastes 0-1 bytes, and it always wastes 1 byte when you give it a multiple of 8 bits. The QUIC method adds 2 bits and then rounds up to the nearest power of two bytes. On values up to 62 bits it wastes 0-4 bytes, and it wastes 1-4 bytes when you give it a multiple of 8 bits. The rounding has a much bigger impact than the bits directly used to encode length.
- lifthrasiir 2y agoNo, virtually all integer VLE schemes do have a set of optimal distributions where they are particularly good at, and this one is no exception (in fact, its set of optimal distributions is identical to many others). The only thing that can be considered strictly "wasted" here would be the existence of multiple overlong sequences.