Performance Guidelines for Properties

re: Performance Guidelines for Properties

ricom — Thu, 05 Jan 2012 03:13:14 GMT

Umm... in 21 years? :)

re: Performance Guidelines for Properties

Reiley Yang — Thu, 05 Jan 2012 00:20:55 GMT

Great to see your blog being active again.

When shall I expect to see a series of "History of Internet Explorer"? :)

re: Performance Guidelines for Properties

ricom — Wed, 21 Dec 2011 20:16:06 GMT

@Chris: This is a strange pattern, the class in question is accepting a list of Bars from anyone at all and you're willing to lazy-init an empty list in the event that you don't have one yet. Normally I'd say you should be careful not to expose your guts like that but in this case we're clearly talking about some kind of argument acceptor/builder.

The lazy init stuff often ends up being more trouble than its worth. Consider:

if (yourThing.Bars.Count == 0) {

...

}

Now we made an empty list just so we could see that it's empty?

Following the no-alloc rule if you have a read-only empty ilist that can't be changed and you returned that then you get a much better pattern.

_bars = mySharedReadonlyEmptyList;

public IList<Foo> Bars { get { return _bars; } set { _bars = value }}

Life is good. Count is free. Bars is simple. 10/10.

But that whole pattern is scary... you can't assume anything about Bars from call to call becuase they can change the guts of the list and you would never know.

This is really a whole different kind of sin.

re: Performance Guidelines for Properties

Chris Marisic — Tue, 20 Dec 2011 21:10:47 GMT

What about properties that behave as such?

public IList<Foo> Bars { get { return Bars ?? (Bars = new List<Food>()) } set { _bars = value }}

I actually hate having to define these setters and targeting a backing field. Seems like something the auto property should be able to handle. or a keyword like _field = value etc.

re: Performance Guidelines for Properties

ricom — Tue, 20 Dec 2011 19:47:50 GMT

@Daniel: indeed I like it much better than the auto-init flavor

@Martin: of course you're right: it's all about the tradeoffs but on the other hand I do like to prime the pump if you will with what greatness looks like. At least to my eyes :) Thanks for the reference, a lot of truth there too.

re: Performance Guidelines for Properties

Daniel Neely — Tue, 20 Dec 2011 14:06:07 GMT

I think I wasn't clear enough in my first comment. Throwing an exception for a lazy initialized property eliminates the potential performance surprise from first access that would occur if the null check called the initializer, but does so at the cost of breaking the encapsulation of the lazy initialization because the caller needs to explicitly call the initialization method. I'm not sure that tradeoff is worthwhile since you're making things harder on the caller; and if a future version is able to replace the heavy initialization with something light enough not to need special behavior you're forced to modify all the using code to make the change.

re: Performance Guidelines for Properties

Martin Jul — Tue, 20 Dec 2011 12:12:06 GMT

From a performance point you are spot on, but it is also relevant to look at it from a design point of view. Properties (and fields) tend to expose implementation details, leading to tightly coupled code, as argued in the classic article by Allen Holub, “Why getter and setter methods are evil”

(you have to forgive the Java folks that they did not have properties back when he wrote that):

www.javaworld.com/.../jw-0905-toolbox.html

"Though getter/setter methods are commonplace in Java, they are not particularly object oriented (OO). In fact, they can damage your code's maintainability. Moreover, the presence of numerous getter and setter methods is a red flag that the program isn't necessarily well designed from an OO perspective. "

His point is that properties tend to give the illusion of encapsulation, while actually exposing implementation. Fields are more honest about exposing zero-behaviour implementation details. The alternative is using double-dispatch, interfaces etc. but most people consider that a lot of work in languages like C# and tend to prefer properties for that reason.

I think a good rule of thumb for using fields/properties is to at least encapsulate the value they give out, e.g.

Don't give a Price field the type "double" just because it would currently fit in that data type. Create a Price or Money struct instead and expose that. Then it's easier to change the implementation when you realise that doubles have rounding errors that are not acceptable. From a perf view this should be just as good, from a design view the semantics of the field are much clearer, and from a maintainability view it saves you a lot of trouble.

In any case remember, it’s all about trade-offs, not absolutes.

re: Performance Guidelines for Properties

tobi — Tue, 20 Dec 2011 08:36:33 GMT

All of this article is very true and best practice. In the performance hot-spots for performance reasons, in the cold-spots for maintenance reasons. Although the rules in the latter case are relaxed.

re: Performance Guidelines for Properties

Henry Boehlert — Tue, 20 Dec 2011 07:08:19 GMT

Even if I follow your recommendation (prefer field/hashtable-backed properties), it still will be hard for the compiler to reason whether my property value can change between two calls to get_Property and more often than not it won't be able to optimize away the second call.

It is still a pity .NET (or C#/VB, fwiw) don't support const declarations in the C++ sense, or at least real read-only properties. That would give the compiler at least some hint and could even provide support for virtual properties.

re: Performance Guidelines for Properties

ricom — Tue, 20 Dec 2011 02:56:30 GMT

I just added the bit about properties not causing side-effects, I'd meant to include that and forgotten.

Properties that might be fast or might not be fast, that might fail or might not fail, are a major source of problems.

@Daniel: The exact example that you give above has no allocations on the non-exceptional path and a clean failure path so I wouldn't worry about it. But really simpler is better. And as Bjorn says, just changing it to a function is enough to make it clear that there is more there than meets the eye.

Remember, "The code is more what you'd call 'guidelines' than actual rules..."