The C++ parser has been completely rewritten in the last few years to push the current code generation design to its limits. The biggest obstacle in the way of optimizing it further is legacy APIs, especially std::string for string fields, which forces tons of small heap allocations and frees and defeats the benefits of arena allocation.
Changing very widely used APIs is not easy, these things take time.
It's exposed in the API. When you access a string field in protobuf, say foo.my_str_field(), the return type is const std::string&. We have to have a real std::string internally to return a reference to it.
The C++ parser has been completely rewritten in the last few years to push the current code generation design to its limits. The biggest obstacle in the way of optimizing it further is legacy APIs, especially std::string for string fields, which forces tons of small heap allocations and frees and defeats the benefits of arena allocation.
Changing very widely used APIs is not easy, these things take time.
Interesting, thanks for the clarification, however why do libraries depend on what should be implementation details of generated code to start with?
Something that by good CI/CD practices shouldn't even be part of checked in code.
It's exposed in the API. When you access a string field in protobuf, say foo.my_str_field(), the return type is const std::string&. We have to have a real std::string internally to return a reference to it.
1 reply →
haberman is part of the “they” here (he’s on the core protobuf team, does things like this).