2

我们正在使用 protobuf-net 序列化和反序列化深度对象图。这些图的某些成员实际上在许多图上一遍又一遍地重复，就像与少数对象的多对一关系一样。例如，一个Sale对象是一个图，它的Store成员（可能是它自己的一个子图）将只是 10 个可能的商店中的一个，因此它会在许多消息中一遍又一遍地重复（销售图）。

如果我们能够以某种方式缓存这些对象的序列化，我们可以获得明显的性能优势。理想情况下，我们想告诉RuntimeModel某些类型 - 在本例中为Store - 应该通过一个可扩展点来处理，就像代理一样，但是我们能够提供原始序列化字节。

我们的限制之一是生成的消息仍应与 protobuf-net 兼容，以便在没有这些“钩子”的情况下由其他平台（例如 Python）中的客户端直接解析（Python 客户端的螺丝性能优化！）。

我们查看了代理项，但看起来无论代理项产生什么（在我们的例子中，这将是一个字节[] 数组）（如您所料）仍然会被序列化为它的类型（即作为一个 字节[] 数组）因此与Python 客户端期望的Store对象不兼容。

我们还研究了扩展，即使我们以某种方式在一个额外的字段中破解了缓存的序列化存储，我们也会回到 Python 客户端。

对于这种情况，我们可能会使用任何其他可扩展性机制吗？

4

1 回答 1

1

哦，有趣。确实，python 要求偏离了我要说的内容（参考跟踪）。您可以做的是首先将它们序列化为 a byte[]each （通过MemoryStream），然后将该数据作为byte[]成员包含（ a 和原始对象之间没有区别byte[]- 外部客户端不会注意到任何差异），但想法发生了在大多数情况下，这不会比保持对象模型“原样”并多次序列化一些节点（序列化不是很慢）快得多。

不过，坦率地说，我会考虑以不同的方式存储它 - 因此，我不会将存储存储为子节点，而是将它们唯一地作为顶级节点一次，并将一些唯一标识符存储为查找（不是子对象本身）。不过，这会改变布局。

不，没有内置任何东西来支持这一点，我不确定它是否是支持的关键场景。

于 2012-08-11T07:39:34.247 回答