.net 如果使用AsReference限定符，性能损失有多严重？

我必须决定是否要在550K总数中减去额外的5K，通过使用AsReference对一处房产进行鉴定。毕竟，5公里只是总数的一小部分——不到1%。尽管如此，如果性能惩罚很小，为什么不呢

谢谢

澄清

---

如果确实存在共享引用，那么使用AsReference确实可以减少大小。我的问题是关于性能或者直截了当地说——速度

这显然取决于模型，这里的序列化和反序列化是不同的。对于中等大小的模型，性能开销将是最小的，当然，它通常具有较少的实际序列化要做（假设有合理数量的重复对象实例标记为

AsReference

；如果根本没有，那么开销虽然很小，但是浪费的）。如果引用意味着我们避免了重新序列化一个大的数据分支（可能是一个子集合等），那么我们可以在CPU和带宽方面获得一些非常好的节省

这里的任何代价都纯粹是通过序列化来感受的，因为有问题的部分是检查我们以前是否见过对象。在反序列化过程中，只需按索引从列表中提取项，速度非常快

还要注意，我假设这里禁用了

DynamicType

，因为这是一个单独的问题（同样，影响是最小化的）

再储存；当前，维护一个平面列表，并检查引用是否相等。我希望使用哈希表/字典查找，但我担心重写

GetHashCode（）

/

等于

的类型，遗憾的是，无法访问原始的

对象.GetHashCode（）

实例方法。这意味着，对于标记为

AsReference

的大量成员（这里我指的是图形中的数千个对象），它可能会慢慢降级（对于长度N不断增长的列表，查找将是O（N））。将此更改为哈希查找将使每次查找时的值为O（1）

大声思考，当我们可以证明类型没有重写时，我们可能会做一些事情（尽管这涉及更多的反射，这本身就是一件痛苦的事情），或者我们可以信任用户不要把

GetHashCode（）

等弄得一团糟，并使用他们对相等的定义来表示图形中的相等。我愿意在这里思考，但目前引用平等被用作最安全和最简单的选择

---

对于实际数字：这在很大程度上取决于您的型号和尺寸；由于您有一个方便的型号，并且知道带/不带

作为参考的大小，您大概可以将其包装在
秒表或类似的东西中（最好是
内存流
之类的东西，因此您在计时中不包括磁盘/IO成本）。
谢谢您指导我回答我的一个老问题。我已经编辑了问题-添加了澄清。感谢您的详细回答。@Marc，在序列化过程中，您不能在字典中进行O（1）搜索，而不是在平面列表中对已经遇到的对象进行O（N）搜索，其中键是ObjectedGenerator（使用RuntimeHelpers.GetHashCode（）返回的标识）安德斯：哦，太棒了；GetHashCode（）是我在上面讨论的方法（没有找到）。这样，我就可以编写一个引用相等哈希查找了，当然