……如果你围绕这些问题设计一个proto schema，为了绕过Go protobuf本身的糟糕实现决策，你可能会严重影响可读性和可维护性。我曾经做过这种优化，但当我的团队看到基准测试数据后，他们认为这是值得的。在技术项目中，你并不希望做出这样的决定，但我要强调的是，在许多情况下，这仍然是正确的选择。Rust的prost crate并不是官方的，但它已经让你对schema有更多控制。你可以在技术上使用自己的Rust代码而不是生成的代码，不过我还没看到有人真的这么做，而且这似乎也不被鼓励。无论如何，我最大的问题在于prost使得共享子消息变得困难（或可能目前不可能）使用Arc [2]，而另一方面，使用Go只需使用*就可以轻松实现。虽然prost在更多情况下避免了分配，但根据我的经验，它避免复制的次数更少，而其中一些复制仍然需要分配。……
源讨论揭秘protobuf的wire格式原帖 71 条评论 · 导入时统计我觉得很有趣的是，那些对Protocol Buffers大喊大叫的人却在使用它与gRPC结合。问题真的出在传输格式上，还是所有上层的东西都有问题？ 我一直在用Protocol Buffers进行一个（非网络）业余项目，发现它相当容易使用，尤其是在跨多种实现语言工作时。对我来说，它似乎在JSON的易用性和手写序列化格式的效率之间找到了一个很好的平衡点。
完整原文把你的经验，加入这段讨论。
关于开销，以Go语言为模型也无意中影响了其他出色的.NET gRPC工具。很多类型本可以基于标准库类型而不是protobuf的 - RepeatedField<T>其实就是List<T>，只是强制重新分配缓冲区。也可以是T[]，并要求用户自己获取。或者使用池化的类型。 对于短期存在的RepeatedFields来说这不是问题 - 它们在Gen0堆中死亡，GC只是忽略它们，但成本确实存在，并且在所有这些新的向量数据库库传递1536长度的F32缓冲区时被感受到。
完整原文大小是在写入对象之前通过遍历对象树计算的。如果你想要一个超级快速的实现，可以为一个比如说三个字节的VarInt预留空间，然后不管是什么都写成三个字节。一个四个字节的VarInt仍然可以有效表示数字5，尽管这通常只需要一个字节。 我对Protocol Buffers感到恼火的是，其传输格式不区分不同类型的二进制数据：如果它说明“这是一个对象二进制”，那么即使我们没有协议定义，我们也可以对其进行分解。目前的情况是，它可能是字符串、数组或对象。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。