Take the 2-minute tour ×

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.

share|improve this question
It's not really a good idea to embed lots of functionality in getters or setters, rather use Get* and Set* methods instead - this provides a hint to the consumer that there is more than trivial functionality involved. –  Eric Smith Jun 17 '09 at 5:46
add comment

6 Answers

up vote 8 down vote accepted

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.

share|improve this answer
add comment

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.

share|improve this answer
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 Jun 17 '09 at 5:53
add comment

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.

share|improve this answer
Then why does this page on MSDN msdn.microsoft.com/en-us/library/ms229054.aspx say that methods are much faster than property access? –  Pedery Jun 17 '09 at 6:19
Where does it say that? –  Jon Skeet Jun 17 '09 at 6:34
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 Jun 17 '09 at 18:17
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 Jun 20 '09 at 18:41
add comment

They're no different from methods.

share|improve this answer
add comment

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.

share|improve this answer
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 Jun 17 '09 at 6:34
Well, as others have noted, properties are just methods, so it's more a design question than a performance question. –  On Freund Jun 17 '09 at 6:39
Are you sure about this? I read elsewhere that setting/getting properties is a lot slower than using methods. –  Pedery Jun 17 '09 at 18:19
Properties are implemented in terms of methods. The performance of both are identical. –  On Freund Jun 18 '09 at 5:46
add comment

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.

share|improve this answer
That sounds unlikely. If you examine the IL generated by properties and a simple manual Get/Set method it is identical. –  lidgren Jun 20 '09 at 18:52
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 Jun 20 '09 at 18:57
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 Jun 21 '09 at 4:14
add comment

Your Answer


