字段与属性的实际性能

发布于 2024-10-06 22:54:22 字数 478 浏览 3 评论 0原文

我正在做一些构建后的 CIL 编织,将 CIL 添加到程序集中的所有方法(换句话说,大量方法)。每个方法都会检查特定值是否为空。示例(CIL 代码的 C# Reflector 版本):

// CIL woven region start
if (MyType.Something == null) {
 // ... some new stuff
}
// CIL woven region end

将 MyType.Something 作为属性与字段相比,对性能有何影响?我知道我读过 C# 编译器执行特殊优化,在这种情况下应该不会对性能产生影响...但是如果是直接 CIL 代码(没有 C# 编译器)呢...?或者是 JIT 编译器允许这些优化(因此直接 CIL 代码仍然受益)?

为静态属性的访问器发出 OpCode.Call 的性能是否会比 Ldsfld 差(请记住,由于程序集中的每个方法都是编织的,因此这需要数万次调用)?

谢谢。

I'm doing some post-build CIL weaving that adds CIL to all methods in an assembly (in other words tons of methods). Each method checks if a specific value is null. Example (C# Reflector'd version of CIL code):

// CIL woven region start
if (MyType.Something == null) {
 // ... some new stuff
}
// CIL woven region end

What is the performance impact of having MyType.Something as a Property vs. a Field? I know I've read that the C# compiler performs special optimizations and there should be no performance impact in that case...but what about in the case of direct CIL code (no C# compiler)...? Or is it the JIT compiler that allows for these optimizations (so direct CIL code still benefits)?

Will emitting OpCode.Call for the static property's accessor have poorer performance than Ldsfld (bear in mind this is across tens of thousands of invocations since every method in the assembly is woven)?

Thanks.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

深居我梦 2024-10-13 22:54:22

在为 SlimDX 开发数学库时,我们发现,在 .NET 3.5 SP1 之前的框架上,使用数学类型成员的字段(例如 Vector3 的 X、Y、Z)会比属性带来不成比例的性能提升。换句话说,对于大量访问属性的小型数学函数来说,差异是显而易见的。

自 .NET 3.5 SP1 以来,这一点得到了改进(请参阅 JIT 输入)。虽然我相信之前的 JIT 仍然会内联小方法(属性毕竟只是方法),但早期框架中存在一个错误,阻止内联采用或返回值类型的方法。

请注意,即使存在差异,差异仍然很小。除了对性能最关键的情况外,我仍然会选择在所有情况下使用属性。

When developing the math library for SlimDX, we found that, on pre-.NET 3.5 SP1 frameworks, using fields for the members of the math types (such as X, Y, Z for a Vector3) gave a disproportionate performance increase over properties. In other words, the difference was noticeable for small math functions which heavily accessed properties.

This has since been improved since .NET 3.5 SP1 (see JIT inling). While I believe that the JIT prior to that will still inline small methods (properties are simply methods after all), there is a bug in the earlier frameworks that prevented inlining of methods that take or return value types.

Note that the difference, when there, is still quite small. I would still elect to use properties in all but the most performance critical cases.

梦亿 2024-10-13 22:54:22

C# 编译器不会对此进行优化,不会,但据我所知,JIT 编译器通常可以内联琐碎(和非虚拟)属性。

与所有性能问题一样:如有疑问,请进行测试!

The C# compiler won't optimize this, no - but the JIT compiler can usually inline trivial (and non-virtual) properties as far as I'm aware.

As with all performance questions though: when in doubt, test!

独留℉清风醉 2024-10-13 22:54:22

任一方向的影响都很小。如果您的属性看起来像这样::

public static SomeType PropertyName
{
    get {return MyType.propertyName;}
    set {MyType.propertyName = value;}
}

确实应该有一个非常小的差异。 Jit 编译器应该将 call MyType.set_Property 内联到字段加载中,但即使由于错误而无法实现。我个人会谨慎行事并坚持使用属性设置器和获取器,因为方法主体可能会发生变化,因此原始字段访问/突变可能还不够。

如果您想测试,可以强制您发出的方法使用关闭内联或优化的 MethodImpl。然后比较一下差异,我真的怀疑差异会很大。

The effect is minor in either direction. If your properties look like this::

public static SomeType PropertyName
{
    get {return MyType.propertyName;}
    set {MyType.propertyName = value;}
}

There genuinely should be a very minor difference. The Jit compiler should inline the call MyType.set_Property into a field load, but even if it couldn't due to a bug. I'd personally err on the side of caution and stick with the property setters and getters as potentially the method body might change, and as a result the raw field access/mutation may not be enough.

If you'd like to test you can force the method you emit to use the MethodImpl that turns off inlining or optimizing. And then compare the difference, I really doubt it'll be significant.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文