3 ms·
IF your protobuf is string-heavy then the C++ code is actually not as efficient as it could be because it copies the field into a new std::string. It does not
by secondcoming 4y ago
IF your protobuf is string-heavy then the C++ code is actually not as efficient as it could be because it copies the field into a new std::string.
It does not support std::string_view (or any equivalent).
Google's internal protobuf does support ABSL's string view though, but it's not public.
- anonymoushn 4y agosimdjson also does this sort of thing. All strings are decoded and copied to an auxiliary buffer. For strings without escape sequences in them or for end users who don't mind destroying the json document by decoding the strings in-place, these copies could be avoided. I may get around to shipping a version of simdjzon (the Zig port) that optionally avoids these copies (this sort of has to be optional because the current API lets you throw away your input buffer after parsing, and this option would mean you cannot do that), but porting this stuff back to C++ and getting it upstreamed sounds more difficult.
- secondcoming 4y agoyes, rapidjson also supports optional insitu parsing.
- tylerhou 4y agoCopying into a string is a safe default. Also, proto’s API currently returns string references (and not views) so making a copy is required for open source. (Although now std::string_view is common, I hear rumors that the proto API might change…)
- secondcoming 4y agoI don't think it was about safety. It was because they didn't want to make ABSL part of the public API.
- tylerhou 4y agoMaybe that's true, but safety is an additional concern. You have way more lifetime headaches if you alias the underlying data. Copying avoids all that.