【问题标题】:Automatic Properties vs Property with variable - performance consideration自动属性与具有可变性能考虑的属性
【发布时间】:2013-09-02 05:10:15
【问题描述】:

我了解差异。两者之间。并阅读与此相关的线程。我的问题是关于任何性能提升。我曾经使用局部变量创建属性。每当我在类内部使用属性时,我都会使用局部变量而不是属性。我认为这样做有一点好处,而不是调用属性然后调用局部变量的属性。在自动属性中是不可能的。我的假设正确吗?我的方法有什么好处(可能很少)吗?

样本

Public class class1
{
 private int _someField;
 public int SomeField
 {
  get{return _someField;}
  set {_someField = value;} 
 }

 Public void Insert()
 {
     str= "insert into table values(" + SomeField + ")  
     //or is it better to use like this?
    str= "insert into table values(" + _someField + ")

 }  
}

【问题讨论】:

  • 获得的性能不是很多。但是,Property 是一个代码包装器,它可以包含比 get { return ...;}set { ... = value;} 更多的代码,例如用于触发一些相关事件。
  • 是的,我使用财产。问题不在于属性与变量。它的关于属性使用局部变量而不是使用
  • @KingKing - 好吧,自动属性 ​​(Property { get; set; }) 不会有更多逻辑。 - 对 OP 来说,这是你可以很容易地自行分析的东西。但我只想说,如果那是你的瓶颈,那么你可能还有其他问题......
  • @Corak 我谈到了manual Property,我不是新手不知道Auto Property 是什么。

标签: c# properties


【解决方案1】:

无论您使用编译器转换为方法调用的自动属性.. 还是直接访问支持字段.. JIT 编译器很可能无论如何都会内联字段访问。

编辑:

自动属性被编译成方法调用。所以这个:

public string Property { get; set; }

..变成:

private string _property;

public string get_Property() {
    return _property;
}

public void set_Property(string value) {
    _property = value;
}

JIT compiler 看到这一点时,它可能会内联字段访问(它确实是一个主要的候选者)。因此,如果你这样做:

Property = "some value";

它不会生成这个:

set_Property("some value");

更有可能这样做:

_property = "some value";

所以,真的,根本没有惩罚。重要的是要注意这是特定于实现的(特定于 JIT 编译器实现)。但老实说,如果这种东西不是内联的候选者,我不知道是什么!

【讨论】:

  • 对不起,我没有正确理解。你能解释一下吗?顺便说一句,我使用 .net
  • 我理解你的问题..这直接回答了它。我建议单击我提供给 JIT 编译的链接并查看您的 .NET 代码如何成为机器代码。答案基本上是“没有性能差异”。
  • 好的。所以如果调用 get_Property(somefield) 它会识别它是一个自动属性并会直接读取支持字段?
  • 没有。你打电话给Property。 C# 编译器生成一个get_Property() 方法,然后调用该方法。然后,JIT 编译器可能直接访问_property,而不是调用get_Property()
【解决方案2】:

当您还没有自己创建字段 (Automatic property) 时,编译器将为您生成支持字段。因此,根本没有性能提升。

这是 MSDN 所说的

在 C# 3.0 及更高版本中,自动实现的属性使 当不需要额外的逻辑时,属性声明更简洁 在属性访问器中。它们还使客户端代码能够创建 对象。当您声明一个属性时,如下所示 例如,编译器创建一个私有的、匿名的支持字段, 只能通过属性的 get 和 set 访问器访问。

所以,

private int _someField;
public int SomeField
{
    get{return _someField;}
    set {_someField = value;} 
}

等价于

public int SomeField {get;set;}

在 Corak 的评论之后,我想补充一点,如果您的属性没有任何逻辑然后是简单的分配(如上面的示例),那么

someClass._someField

将是相同的(嗯,几乎)

someClass.SomeField

而且,如果您认为这是您的瓶颈。然后再想一想。不可能。

【讨论】:

  • 问题是,如果在课堂内使用_someField而不是SomeField会更快。
  • 当然使用_someField 比使用SomeField 更快,但这并不重要。我们必须根据性能以外的其他因素在_someFieldSomeField 之间进行选择。
  • @KingKing 我喜欢你这样坚定的声明,我们中的一些人不会仅仅因为它不提供“纯”性能而做出一些重要的设计选择,但不可避免地会因为性能受到惩罚一些抽象在现代 OO 语言中......你可以摆脱它对现代 C++ 和可能其他我不知道的预编译语言的聪明,但这是另一个故事......
猜你喜欢
  • 2017-03-26
  • 2011-01-14
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2016-03-29
  • 1970-01-01
相关资源
最近更新 更多