在 C# 中定义自定义类型的属性时是否存在任何性能问题？

Question

Say I have four classes A,B,C and D.

D has property: Name(string)

C has property: D1(type D)

B has property: C1(type C)

A has property B1(type B)

With A1 as instance of A, I can access: A1.B1.C1.D1.Name

Is there any performance issue with this?

How deep can a property residing won't be any huge performance hit?

Or is there a limit to this hierarchy?

Answer 1

There is no performance issue, it can go as deep as you want (to a certain limit if I remember correctly. However, if you hit that, you have other, more pressing, problems).

Also, while going down the object graph isn't really expensive, arbitrary code in the getters might be.

Answer 2

If all the properties in the chain are sealed (the default) and the getters are trivial, then the JITter will probably be able to inline the chain of calls. You will incur a sequence of pointer lookups, so this technically won't be as fast as if A had a copy of Name, but the overhead is unlikely to be significant.

If any of the properties in the chain are virtual, then I believe the JITter will not be able to inline the calls, and you will incur the overhead of one or more function calls (the property gets). That is still extremely small though (again, still assuming the getters are trivial).

As always, the only way to be sure is to measure. And be conscious of what you are measuring: if the nested chain turns out to be, say, 50% slower than A having its own copy of Name, that doesn't mean it's a big deal, unless your program spends a large amount of its runtime on that Name get -- highly unlikely! So do the right thing first -- make the program readable and maintainable first -- and if you measure and find it to be a bottleneck, then look at optimising it.

Answer 3

With some quick profiling, on my machine a ++ on a trivial property that is one level deep runs in 3 nanoseconds, the same property when nested 10 deep runs in 6 nanoseconds... so if you are doing this a couple million times a second it might be something to look at, but in most cases its going to be insignificant.

Answer 4

Given that you don't over do, no it's not an issue. In real world scenarios object oriented programming requires these type of properties, for eg person.personalDetails.address.city

Answer 5

I haven't been doing any .net for a while now, so take my answer with the due doubts. I think the compiler should optimize the getter - unless it's doing something very complicated. What's left is the penalty you pay for jumping to a different address in memory. As an example, your objects in memory could be in any order, like this one: D [other data] C BA So, for each get you're asking for an address backward in memory, which is likely to cause small slowdowns and very likely page faults (this is also true in other cases). However, this is only to answer your question. In practice, you hardly need to take this into account. Unless you're writing some inner loop of a time-critical and very complex algorithm, the difference in execution time is really close to 0.

A best practice in such a case if you need to use your string very often is to store a reference to it and use that reference instead of calling your chain of properties. If you don't gain anything in speed, at least you get code that is easier to read, to type and to maintain.