在读/写操作中,属性与支持字段之间是否存在性能差异?

如果属性是一个直接的get/set,那么它被编译掉了——换句话说,编译器将使用属性或字段直接转换成相同的东西——所以没有性能差异。

然而,get/sets可以包含他们想要的任何逻辑,因此成本可能很高——然而,指导方针经常建议保持它们的轻量级。

属性有一些好处,即使它们只是get/set covers:

• 数据绑定只能查看属性,不能查看字段。
• 它符合封装的概念。
• 您可以强制执行只读或只写语义。
• 可以将属性单独应用于基础字段(在序列化场景中很有用)。

顺便提一句,尽管回顾这些东西的微小性能特征很有意思——在应用这种优化类型的生产代码中(在本例中没有这样的优化类型),会 可能的 站在过早优化的旗帜下。

这要看情况而定。从技术上讲,它可能会变慢,但即使在这些情况下,它也几乎是不可察觉的。下面是如何使用方法内联的规则 here .

• 大于IL 32字节的方法将不会被内联。
• 虚拟函数没有内联。
• 具有复杂流控制的方法将不在列中。复杂流控制是除if/then/else之外的任何流控制;在这种情况下,是切换或while。
• 包含异常处理块的方法不是内联的,尽管引发异常的方法仍然是内联的候选方法。
• 如果该方法的任何形式参数是结构,则该方法将不会被内联。

由于C编译器从属性声明创建单独的getter和setter方法,很明显,它们将被彼此独立地处理。根据上面的规则,我会说大多数时候属性访问器是内联的。我认为有关方法必须是非虚拟的规则将是经常发生的重要的ShowStopper之一。

在性能上不应该有差别。如果你使用 Reflector 要查看代码的反汇编,它会以最简单的方式自动为您创建支持字段。它实际上只是您的编译器为您提供的语法糖分,使您的生活更容易。

如果一个类或结构公开了一个结构类型的可变字段,则可以访问该结构的各个字段而不必复制整个字段。相反,如果它公开一个属性(可变或不可变)或“只读”字段,那么访问结构的任何部分将导致系统复制整个结构,然后访问副本。此外,使用者代码可以方便、高效地修改公开结构字段的字段,而不需要任何冗余的复制操作。相反,如果结构作为属性公开,则修改其中的任何部分将需要使用者将其复制到一个临时变量中,进行更改,然后将其存储回去,一系列步骤可能会导致整个结构复制四次(在读取时,供应商和使用者各复制一次,然后再次复制一次)写作时)。