使用AsReference限定符的性能损失有多严重（如果有的话）？

Question

我必须通过使用AsReference对一个属性进行资格认定来决定是否要从550K中减去额外的5K。毕竟，5K只是总数的一小部分 - 不到1％。如果性能损失微乎其微 - 为什么不呢？

感谢。

澄清

如果实际存在共享引用，则使用AsReference确实会减小大小。我的问题是关于表现还是直截了当 - 速度。

Answer 1

显然取决于模型，序列化和反序列化在这里会有所不同。对于中等大小的模型，性能开销将是最小的，除了它当然通常会有更少的实际序列化（假设有合理数量的重复对象实例标记为AsReference;如果有什么都没有，然后开销，虽然最小，是浪费）。如果引用意味着我们避免重新序列化大数据分支（可能是子集合等），那么我们可以为CPU和带宽节省很多。

这里的任何成本都是纯粹由序列化感觉到的，因为有问题的部分是检查我们之前是否已经看过该对象。在反序列化期间，它只是按索引列表中的pluckign项，所以非常快。

另请注意，我假设DynamicType 已禁用，因为这是一个单独的问题（同样，影响最小化）。

再储存;目前维护平面列表，并检查引用是否相等。我想使用哈希表/字典查找，但我担心覆盖GetHashCode() / Equals的类型，遗憾的是无法访问原始的object.GetHashCode()实例方法。这意味着对于标记为AsReference的非常大数的成员（这里我指的是图中的数千个对象），它可能会慢慢降级（查找将为O（N）越来越多的长度列表N）。将此更改为哈希查找将使其在每次查找时都为O（1）。

大声思考，当我们能够证明类型没有覆盖时，我们可以可能做某事（虽然这涉及更多的反思，这本身就是一种痛苦），或者我们可以< / em>只是相信用户不要弄乱GetHashCode()等 - 并使用他们的相等定义来表示图中的相等性。我对这里的想法持开放态度，但目前引用平等被用作最安全和最简单的选择。

对于实际数字：它很大程度上取决于您的型号和尺寸;因为你有一个方便的模型，并且知道有/ AsReference的大小，你可能会把它包裹在Stopwatch或类似的地方（最好是MemoryStream之类的东西，所以你在时间上不包括磁盘/ IO成本。