The current golang protobuf api / implementation is unsuitable for large scale system. See https://groups.google.com/forum/#!topic/Golang-nuts/vxJNXdiM... for discussion (you have to scroll down the thread a bit).
However, it does not make them unsuitable. We have many large scale systems at Google written in Go using this proto library. Some are high QPS, some use large protos, some have complex definitions. Each requires care and thought, but they work.
Proto decoding specific: if you're parsing a message with lots of fields, you can define a new message with just the fields you care about. I.e. if you're parsing
message M {
optional int32 F1 = 1;
// ...
optional int32 F100 = 100;
}
but you only care about F1 and F2 in this message, define message SmallM {
optional int32 F1 = 1;
optional int32 F2 = 2;
}
If you use SmallM to decode your messages, it will skip a lot of work filling out fields F3-F100, saving you a lot of CPU.