为什么公共领域比属性更快？

我在XNA中闲逛,发现其中的Vector3类是使用公共字段而不是属性.我尝试了一个快速的基准测试,并发现,struct差异非常大(将两个向量组合在一起,1亿次带有2.0s属性和1.4s带字段).对于参考类型,差异似乎并不大,但它存在.

那为什么呢？我知道属性被编译成get_X和set_X方法,这会导致方法调用开销.但是,这些简单的getter/setter是不是总是被JIT内联？我知道你无法保证JIT决定做什么,但肯定这在概率列表中相当高？还有什么将公共领域与机器级别的财产分开？

有一点我一直想知道:自动实现的属性(public int Foo { get; set; })比公共领域"更好"的OO设计？或者更好地说:那两个有什么不同？我知道用反射把它变成一个属性更容易,但其他什么呢？我打赌这两个问题的答案是一回事.

BTW:我使用.NET 3.5 SP1,我相信固定的问题,其中有结构的方法(或方法的结构,我不知道)均未成行,所以这不是它.我认为我至少使用它,它肯定安装但是再次,我使用Vista 64位SP1应该有DX10.1,除了我没有DX10.1 ..

另外:是的,我一直在运行发布版本:)

编辑:我很欣赏的快速解答的家伙,但我指出,我不知道,一个属性访问是一个方法调用,但我不知道为什么,大概是,在林立的方法比直接字段访问速度较慢.

编辑2:所以我创建了另一个struct使用显式GetX()方法(o我怎么不完全错过我的Java时间),并且无论我是否禁用内嵌(通过),都执行相同的操作[MethodImplAttribute(MethodImplOptions.NoInlining)],所以结论:非静态方法显然从未内联,甚至不在结构上.

我认为有异常,JIT可以选择虚拟方法调用.为什么不能在没有继承的结构上发生这种情况,因此方法调用只能指向一种可能的方法,对吧？或者是因为你可以在它上面实现一个接口？

这是一种耻辱,因为它真的会让我考虑在性能关键的东西上使用属性,但使用字段会让我觉得很脏,我不妨写下我在C中做的事情.

编辑3:我发现这篇文章的主题完全相同.他的最终结论是,财产电话确实被优化了.我也可以发誓我已经多次阅读过简单的getter/setter属性会被内联,尽管callvirt在IL中.我疯了吗？

编辑4:Reed Copsey在下面的评论中发布了答案:

Re:Edit3 - 看我更新的评论:我相信这是x86 JIT vs x64 JIT问题.x64中的JIT不够成熟.随着越来越多的64位系统每天上线,我希望MS能够迅速提高. - 里德·科普塞

我回答他的回答:

谢谢,这就是答案!我尝试强制x86构建,所有方法都同样快,并且比x64快得多.实际上这对我来说非常令人震惊,我不知道我是在64位操作系统上生活在石器时代.我会在你的答案中包含你的评论,以便更好. - 朱利安

感谢大家!

编辑2:

我在这里有另一个潜在的想法:

你提到你在x64上运行.我在x86上测试了同样的问题,并且在使用自动属性与字段时看到了相同的性能.但是,如果你浏览一下Connect和邮件列表/论坛帖子,有许多在线参考资料,x64 CLR的JIT是一个不同的代码库,并且与x86 JIT具有非常不同的性能特征.我猜这是x64仍然落后的地方.

此外,FYI,在.net 3.5sp1中修复的struct/method/etc事物是在x86端,并且事实上,在.net3.5sp1之前的x86上永远不会内联将结构作为参数的方法调用.这与您对系统的讨论几乎无关.

编辑3:

另一件事:至于为什么XNA使用字段.我实际上是在游戏巨星,他们宣布XNA.Rico Mariani发表了一篇演讲,他提到了许多与博客相同的观点.似乎XNA人员在开发一些核心对象时有类似的想法.看到:

http://blogs.msdn.com/ricom/archive/2006/09/07/745085.aspx

特别是,请查看第2点.

至于为什么自动属性比公共字段更好:

它们允许您更改类的v2中的实现,并根据需要将逻辑添加到属性get/set例程中,而无需更改最终用户的界面.这会对您维护库和代码的能力产生深远的影响.

----来自原帖 - 但发现这不是问题--------

你在 VS 之外运行发布版本吗？这可以解释为什么事情没有得到优化.通常,如果您在VS中运行,即使是优化的发布版本,VS主机进程也会禁用JIT的许多功能.这可能会导致性能基准发生变化.

您应该阅读Vance的这篇文章.它详细说明了为什么方法并不总是由JIT'er内联,即使它看起来应该是完全明显的.

http://blogs.msdn.com/vancem/archive/2008/08/19/to-inline-or-not-to-inline-that-is-the-question.aspx