Databases
StackOverflow2013
Postsdbo
POWhy are public fields faster than properties?
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POWhy are public fields faster than properties?
    primarykey
    data
    text
    <p>I was poking around in XNA and saw that the <code>Vector3</code> class in it was using public fields instead of properties. I tried a quick benchmark and found that, for a <code>struct</code> the difference is quite dramatic (adding two Vectors together a 100 million times took 2.0s with properties and 1.4s with fields). For a reference type, the difference doesn't seem to be that large but it is there.</p> <p>So why is that? I know that a property is compiled into <code>get_X</code> and <code>set_X</code> methods, which would incur a method call overhead. However, don't these simple getters/setters <em>always</em> get in-lined by the JIT? I know you can't guarantee what the JIT decides to do, but surely this is fairly high on the list of probability? What else is there that separates a public field from a property at the machine level? </p> <p>And one thing I've been wondering: how is an auto-implemented property (<code>public int Foo { get; set; }</code>) 'better' OO-design than a public field? Or better said: how are those two <em>different</em>? I know that making it a property is easier with reflection, but anything else? I bet the answer to both questions is the same thing.</p> <p>BTW: I am using .NET 3.5 SP1 which I believe fixed issues where methods with structs (or methods <em>of</em> structs, I'm not sure) weren't in-lined, so that isn't it. I think I am using it at least, it's certainly installed but then again, I'm using Vista 64-bit with SP1 which should have DX10.1 except that I don't have DX10.1 ..</p> <p>Also: yeah, I've been running a release build :)</p> <p><strong>EDIT</strong>: I appreciate the quick answers guys, but I indicated that I <em>do</em> know that a property access is a method call, but that I don't know why the, presumably, in-lined method is slower than a direct field access. </p> <p><strong>EDIT 2</strong>: So I created another <code>struct</code> that used explicit GetX() methods (o how I don't miss my Java days <em>at all</em>) and that performed the same whether I disabled in-lining on it (through <code>[MethodImplAttribute(MethodImplOptions.NoInlining)]</code>) or not, so conclusion: non-static methods are apparently never inlined, not even on structs. </p> <p>I thought that there were exceptions, where the JIT could optmize the virtual method call away. Why can't this happen on structs which know no inheritance and thus a method call can only point to one possible method, right? Or is that because you can implement an interface on it?</p> <p>This is kind of a shame, since it will really make me think about using properties on performance critical stuff, yet using fields makes me feel dirty and I might as well write what I'm doing in C. </p> <p><strong>EDIT 3</strong>: I found <a href="http://www.ademiller.com/blogs/tech/2008/08/c-inline-methods-and-optimization/" rel="noreferrer">this</a> posting about the exact same subject. His end conclusion is that the property call did get optimized away. I also could've sworn that I've read plenty of times that simple getter/setter properties will get in-lined, despite being <code>callvirt</code> in the IL. So am I going insane?</p> <p><strong>EDIT 4</strong>: Reed Copsey posted the answer in a comment below:</p> <blockquote> <p>Re: Edit3 - see my updated comment: I believe this is x86 JIT vs x64 JIT issues. the JIT in x64 is not as mature. I'd expect MS to improve this quickly as more 64 bit systems are coming online every day. – Reed Copsey</p> </blockquote> <p>And my response to his answer:</p> <blockquote> <p>Thanks, this is the answer! I tried forcing a x86 build and all methods are equally fast, and much faster than the x64. This is very shocking to me actually, I had no idea I was living in the stone age on my 64-bit OS.. I'll include your comment in my answer so it stands out better. – JulianR</p> </blockquote> <p>Thanks everyone!</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USJulianR
    1. USJulianR
    plurals
    1. PL
      singulars
      1. LTLinked
    1. PL
      singulars
      1. LTLinked
    2. PL
      singulars
      1. LTLinked
    3. PL
      singulars
      1. LTLinked
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    3. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POWhy are public fields faster than properties?
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POWhy are public fields faster than properties?
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POWhy are public fields faster than properties?
      1. UScgreeno
      1. VTFavorite
    1. COQuestion: What happens if the field is public but there is also a property. Is it inlined then?
      singulars
      1. POWhy are public fields faster than properties?
      1. USQuibblesome
    2. CODoesn't seem like it, no.
      singulars
      1. POWhy are public fields faster than properties?
      1. USJulianR
    3. CORe: Edit3 - see my updated comment: I believe this is x86 JIT vs x64 JIT issues. the JIT in x64 is not as mature. I'd expect MS to improve this quickly as more 64 bit systems are coming online every day.
      singulars
      1. POWhy are public fields faster than properties?
      1. USReed Copsey
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload