message serialization api behavior

[yu chen]

Hi protobuf team,
I noticed that, all MessageLite serialization APIs perform an explicit or implicit flush, except for SerializeWithCachedSizes. Because of this, data may remain buffered and not be immediately readable unless an extra flush is performed, details at https://github.com/protocolbuffers/protobuf/issues/25144.

As a public API, should the behavior of SerializeWithCachedSizes be consistent with the other serialization interfaces? If so, is it possible to add an flush/trim inside SerializeWithCachedSizes, and provide a separate internal-only entry point that preserves the current no-flush behavior for internal callers?

Thanks

[Em Rauch]

I double checked this with the experts on the team and the current behavior is working as intended and we have no plan to change it: SerializedWithCachedSizes is an advanced API for especially performance critical users (easy to do it wrong and be memory unsafe if the sizes as wrong), and it would be a performance regression to guarantee flushing and it's the expected case is for the caller to either trim or drop the steam to sure the data is written out.

Hope that makes sense, thanks!

--
You received this message because you are subscribed to the Google Groups "Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to protobuf+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/protobuf/2eec55c0-63a9-4916-a245-46d3325a1e3dn%40googlegroups.com.