此基准测试似乎表明直接在对象引用上调用虚方法比在对象实现的接口的引用上调用它更快.
换一种说法:
interface IFoo {
void Bar();
}
class Foo : IFoo {
public virtual void Bar() {}
}
void Benchmark() {
Foo f = new Foo();
IFoo f2 = f;
f.Bar(); // This is faster.
f2.Bar();
}
来自C++世界,我原本预计这两个调用都将以相同的方式实现(作为简单的虚拟表查找)并具有相同的性能.C#如何实现虚拟调用以及通过接口调用时显然可以完成的"额外"工作是什么？
好的,答案/评论我到目前为止暗示了通过接口进行虚拟呼叫的双指针解除引用,而不是通过对象进行虚拟呼叫的一个取消引用.
那么请有人解释为什么这是必要的？C#中虚拟表的结构是什么？是否"平坦"(对于C++来说是典型的)或不是？在C#语言设计中做出的设计权衡导致了什么？我不是说这是一个"糟糕"的设计,我只是好奇为什么它是必要的.
简而言之,我想了解我的工具在引擎盖下做了什么,这样我就可以更有效地使用它.如果我不再获得"你不应该知道"或"使用其他语言"类型的答案,我将不胜感激.
为了说清楚,我们没有在这里处理一些JIT优化的编译器,它删除了动态调度:我修改了原始问题中提到的基准,以在运行时随机实例化一个类或另一个类.由于实例化在编译之后和程序集加载/ JITing之后发生,因此在这两种情况下都无法避免动态调度:
interface IFoo {
void Bar();
}
class Foo : IFoo {
public virtual void Bar() {
}
}
class Foo2 : Foo {
public override void Bar() { …我在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位操作系统上生活在石器时代.我会在你的答案中包含你的评论,以便更好. - 朱利安
感谢大家!
我在应用程序中观察到了很多"堆栈内省"代码,这些代码通常隐含地依赖于它们的包含方法没有内联的正确性.这些方法通常涉及到:
MethodBase.GetCurrentMethodAssembly.GetCallingAssemblyAssembly.GetExecutingAssembly现在,我发现围绕这些方法的信息非常混乱.我听说运行时不会内联调用GetCurrentMethod的方法,但我找不到任何相关的文档.我曾多次在StackOverflow上看过帖子,比如这个帖子,表明CLR没有内联交叉汇编调用,但GetCallingAssembly 文档强烈指出不是这样.
还有备受诟病的人[MethodImpl(MethodImplOptions.NoInlining)],但我不确定CLR是否认为这是"请求"或"命令".
请注意,我要求从合同的角度来概述资格,而不是当前JITter的实施由于实施困难而拒绝考虑方法,或者JITter最终在评估交易后最终选择内联合格方法时权衡.我已经阅读了这个和这个,但他们似乎更关注最后两点(有传递提到的MethodImpOptions.NoInlining和"异国情调的IL指令",但这些似乎是作为启发而不是义务呈现).
什么时候CLR 允许内联？