Is size of protobuf serialized data fixed for simple classes?

Question

By simple classes i mean classes/structures that do not contain vectors, stacks, linked list or any other variable length data structures.

1. If we have a class with some simple double, long, int,... fields, does serialized sizes of different instances of this class depend on the value of these fields? (e.g depending on number of meaningful bits, in case of ignoring left 0 bits to save space)

2. How do strings affect size of serialized data?

Answer 1

1: No, it is not usually fixed. By default, int and long (and a few others) are encoded with "varint" encoding (either straight or zig-zag), which is designed to optimize for small magnitude - it is a 7-bit encoding with the 8-th bit used as a continuation flag. However, there are options that allow you to use fixed size (4-byte or 8-byte) encodings for the same data - the DataFormat switch on the ProtoMemberAttribute controls this. double always takes 8 bytes. Additionally, it is possible that some fields may be optional (nullable, with default values, or with conditional serialization), in which case the number of fields in the message is variable.

2: Strings are binary encoded using UTF-8, then the number of bytes is written as a "varint", followed by the payload bytes - so the length of the string, and the particular characters used (since UTF-8 itself uses different numbers of bytes per-character, depending on the character), greatly affect the resulting length.

Answer 2

You need to read the wire format documentation, basically.

The size of floating point fields will always be fixed, but for integers there are options: fixed32 and fixed64 will be fixed (as the name suggests), but int32, int64, sint32, sint64, uint32 and uint64 are variable-length, designed to make encoding of small values efficient.

Strings are encoded as the length of the UTF-8-encoded data, then the data itself. The length itself is serialized in a variable-length format, again so that short strings are encoded efficiently.