Introducing hyperpb: 10x faster dynamic Protobuf parsing that’s even 3x faster than generated code
Today we’re announcing public availability of hyperpb, a fully-dynamic Protobuf parser that is 10x faster than dynamicpb, the standard Go solution for dynamic Protobuf. In fact, it’s so efficient that it’s 3x faster than parsing with generated code! It also matches or beats vtprotobuf’s generated code at almost every benchmark, without skimping on correctness.
Protobuf Tip #9: Some numbers are more equal than others
The first 15 field numbers are special: most runtimes will decode them much faster than the other field numbers. When designing a message type for decoding performance, it’s good to use these field numbers on fields that are almost always present.
Protobuf Tip #8: Never use required
Don’t use 'required' to modify fields—you won’t be able to get rid of it later when you realize it was a bad idea.
Protobuf Tip #7: Scoping it out
buf convert and protoscope are powerful tools for examining and debugging wire format dumps.
Protobuf Tip #6: The subtle dangers of enum aliases
Enum values are a poorly designed feature and shouldn’t be used.
Protobuf Tip #5: Avoid import public/weak
Avoid import public and import weak.
Protobuf Tip #4: Accepting mistakes we can’t fix
Protobuf’s distributed nature introduces evolution risks that make it hard to fix some types of mistakes. Sometimes the best thing to do is to just let it be.
Protobuf Tip #3: Enum names need prefixes
Enums inherit some unfortunate behaviors from C++. Avoid this problem by using the Buf lint rules ENUM_VALUE_PREFIX and ENUM_ZERO_VALUE_SUFFIX.
Protobuf Tip #2: Compress your Protos!
Compression is everywhere. This pervasiveness means that wire size tradeoffs matter less than they used to twenty years ago, when Protobuf was designed.
Protobuf Tip #1: Field names are forever
Don’t rename fields. Even though there are a slim number of cases you can get away with it, it’s rarely worth doing, and is a potential source of bugs.
