Many fields in Protobuf oneof

Is there a performance implication to having a 23-field "oneof" in a protobuf? I'm using proto3.

I am curious particularly about:

Are there boolean flags that need to be parsed for each additional oneof field?
How is the knowledge about which field is "the one" sent over the wire and processed?

Solution

There's a field number for each one in the wire format, which is how the recipient knows which field has been sent.

There's effectively no consequences arising from having lots of fields. About the only thing that takes more time is probably the length of a switch/case (or similar) statement for each field value.

Non-Standard Situations

Oneof's are a bit of an artificial construct anyway - the oneoff-ness is enforced in the class generated from the .proto file, it's not enforced in the wire format. It is possible to send wire format data that has more than one field in it, and all the parser at the receiving end does is silently keep the last one received. You can't send that with the standard generated class (because, it'll have only one field set). Obviously, in this non-standard situation the parser would be having to parse all the received oneoff fields, only to keep just the last one.

So in theory, one could (in a non-standard way) generate parseable wireformat data that would take a long time to parse by having a lot of fields (and repititions of them). This is in contrast to other serialisation standards, where if wireformat of that sort was received the parser would balk at the first hint of there being too many fields and throw an exception / return an error.