C# properties: How are they instantiated?

views:

374

answers:

+1 Q:

C# properties: How are they instantiated?

Hi!

This might be a pretty straightforward question, but I'm trying to understand some of the internal workings of the compilation.

Very simply put, imagine an arbitrary object being instantiated. This object is then allocated on the heap. The object has a property of type PointF (which is value type), with a get and a set method.

Imagine the get and the set method containing a few calculations for doing their work. How and where (stack/heap) and when is this code instantiated?

This is the background for this question:

I'm writing get and set methods for an object and these methods need to be accessed very frequently. The get and set code in itself is rather massive so I feared that in a worst case scenario the methods would be instantiated as an object or a value type with all internal code for every access of the property. On the other hand the code is probably instantiated when the main object is created and the CPU is simply told to jmp to the property code start. Anyway, this is what I want to have clarified.

+1 A:

They're no different from methods.

anthony 2009-06-17 05:43:40

+1 A:

I'm not sure what you mean by instantiated, but if you're worried about the running time of the getter, you can think of caching the response. I wouldn't do that, though, until I've verified that the getter does indeed hurt the performance of your program.

On Freund 2009-06-17 05:44:16

No, it's basically a question wether to have a 250-line setter, or shell it out as a function. The property is used for setting the corners of a rectangular shape (which can be at an angle), so setting a corner will affect also the three other corners and the angle.

Pedery 2009-06-17 06:34:04

Well, as others have noted, properties are just methods, so it's more a design question than a performance question.

On Freund 2009-06-17 06:39:27

Are you sure about this? I read elsewhere that setting/getting properties is a lot slower than using methods.

Pedery 2009-06-17 18:19:28

Properties are implemented in terms of methods. The performance of both are identical.

On Freund 2009-06-18 05:46:12

+3 A:

I don't have my copy of CLR via C# here with me, but getters and setters of properties are just methods on the class with special decoration. Jeffery Richter's excellent book will have all the nitty-gritty details.

Lee 2009-06-17 05:45:36

That's close. When you declare a property, the C# is compiled into a .property in IL which has a .get and .set instance method (if you defined them) named get_PropertyName and set_PropertyName. You can see this if you disassemble something with Reflector that has a property into IL.

jasonh 2009-06-17 05:53:56

+3 A:

Executable code is neither allocated on the stack nor the heap, it is compiled by the JIT'er when required and corresponding memory is set aside once. That is, you're worrying about what is essentially a non-issue. Also, don't try to second guess what the garbage collector does with regards to allocation of memory - it's there to take that worry away from you.

Eric Smith 2009-06-17 05:49:19

Then why does this page on MSDNhttp://msdn.microsoft.com/en-us/library/ms229054.aspxsay that methods are much faster than property access?

Pedery 2009-06-17 06:19:37

Where does it say that?

Jon Skeet 2009-06-17 06:34:01

The bulleted list, after the first code block:"The operation is orders of magnitude slower than a field set would be. If you are even considering providing an asynchronous version of an operation to avoid blocking the thread, it is very likely that the operation is too expensive to be a property."

Pedery 2009-06-17 18:17:54

You're reading it wrong - the text only states you should use a method instead of a property if a particular operation is slow; it says nothing about the speed of invoking a property vs a method (which is the same).

lidgren 2009-06-20 18:41:12

+8 A:

Methods (or properties) do not get instantiated. You seem to be thinking the way that I once did - that creating an instance of a class not only allocates space for the data, but also for the code. This is not true.

Even in C++, the way this would work is that the data would be allocated, along with a pointer to an array of function pointers - the Virtual Function Table or vtable. The entries in the vtable would point to virtual methods. Non-virtual methods would not need an entry in the vtable.

In either case, there was only a single copy of the code, regardless of how many objects were instantiated.

John Saunders 2009-06-17 05:49:43

According to this page on MSDN properties and methods do have some essential differences. Especially when it comes to returning arrays, properties perform a shallow copy of the whole array before returning it, so that is one situation where you want to use a custom function instead.

However, as I explained above, I wanted to know if the program would suffer from a performance penalty if I used properties instead of functions in any way. Overall I did find out that properties are on average about 5% slower than functions for some unexplained reason. It could be because properties boast a whole range of "invisible" objects such as propertydescriptors and the like. Besides that, the implementations seem to be fairly similar.

Pedery 2009-06-20 18:27:15

That sounds unlikely. If you examine the IL generated by properties and a simple manual Get/Set method it is identical.

lidgren 2009-06-20 18:52:32

You're misreading the article. It's stating that you shouldn't use properties for operations that may be expensive. This is more because one doesn't expect a property to do something non-trivial when they use one. And properties don't perform a shallow copy of arrays. The article clearly gives that as an example of what *not* to do with a property.

Jason Baker 2009-06-20 18:57:16

Well, likely or unlikely, I put the exact same content in a property and a function, and called both 100.000 times and measured both using StopWatch. Every single time the function came out about 5% quicker. Something is clearly going on although your point about the IL is valid if that is the case.

Pedery 2009-06-21 04:14:36

ansaurus

tags:

views:

answers:

C# properties: How are they instantiated?

related questions