9

Should we not set default values in optional protobuf fields to minimize data sent over the wire?

I want to minimize my message byte size sent over the wire. To accomplish this, one optimization which I could think of was:

if( message->my_optional_field() != value )
  message->set_my_optional_field(value);

This prevents has_my_optional_field() to be called when the intended value is equal to the default value and hence, prevent the field to appear in the serialization array. Is this a good practice? Does protobuf provide something like this out of the box?

The question is similar to how do has_field() methods relate to default values in protobuf? In fact, it has been answered in one of the comments to the accepted answer. However, subsequent comments have disputed the claim.

Mukul Gupta
  • 2,310
  • 3
  • 24
  • 39

2 Answers2

15

The behavior differs between proto2 and proto3.

Under proto2, the concept of "is present" was separate from the concept of default values. Setting a field to its default value in proto2 is not the same as clearing it; the value would be sent over the wire even though it was the default. In proto2, in order to "unset" the field you had to call clear_my_optional_field(); then it would not be sent on the wire. Proto3 also had the separate has_my_optional_field() method to check whether or not the field was set.

Under proto3, the concept of "is present" has been removed. Instead, a field will be sent if and only if it is not set to the default value. The clear_ method is the same as setting to default. The has_ method no longer exists. Additionally, proto3 did away with the notion of configurable default values -- the default for all fields is 0 or empty.

Exception: For message-typed fields, the behavior hasn't changed in proto3. There is still a concept of presence for these fields.

Kenton Varda
  • 41,353
  • 8
  • 121
  • 105
  • 4
    Interesting indeed. Why did they do away with the notion of configurable default values? That sounds like a step backwards. – Mukul Gupta May 06 '16 at 03:42
  • 6
    @MukulGupta AFAICT, they wanted Protobufs to just be raw structs in Go, and Go doesn't have constructors; it zero-initializes everything. So they changed protobuf. Tail wagging the dog IMO. – Kenton Varda May 08 '16 at 01:42
  • what happens for a mesage-type in which all the subfields in the message are set to the default value? Will HasField called by the receiver on a message-type still return True? (Whereas if no subfields were set, then HasField will return false?) – gunit Feb 08 '19 at 23:23
0

Dont know if this is of any use but if you use the following, you effectively gain the ability to know if its set, so if the value sent in is the default value it knows to output it because it can tell it was set to the datatype.

oneof oneofname{
    int32 variablename = 2;/* the number is the field position within the existing message your declaring the oneof./*
}
Mike Tarrant
  • 291
  • 2
  • 7
  • 19