Nothing but the truth - fields vs. properties - performance differences?

Interesting. Though I never heard of Properties causing performance issues (not Properties without further logic anyway) I guess there could be slight overhead. A Property in .NET is nothing more than a wrapper for a get and set Method. That means that in IL Properties are simply Methods like any other.
Of course you could put a lot of code in Properties (although this is usually not recommended) which could cause performance issues.
Personally I try to call my Properties as much as possible, since they could get some validation logic or call OnPropertyChanged. I just want to make sure I benefit from that code without having to go through my Class to change all the calls to my field into a call to my Property (unless I want to get around this for some reason).
On top of that the performance hit is so very minor that you should not even have to think about it. A few milliseconds for 10000000 read/writes[^]. Optimizing that would be pretty futile :)
Some more on this issue[^].
Self-Implemented Properties versus Public Fields[^] Is that the CP article you referred to?

By the way, speaking from experience, putting to much logic in Properties is a bad idea. I had a Property that made some calls to the database (actually I did a LINQ query on an ObjectContext). When binding to those Properties each value I altered caused my program to hang for about two seconds... Now THAT needed optimization, but not necessarily because they were Properties ;)

Edit:
See Bills comment below. He is completely right and corrects me on an incompleteness in my answer :)

If you want to understand how this actually works out there is a couple of information sources on the net that provides valuable insights:
The blog for the code generation feature team working on the Common Language Runtime (CLR). [^] - these are the guys that that make it possible to generate native code for all binaries that run on top of the Microsoft .NET Framework.

CLR Optimizations In .NET Framework 3.5 SP1[^].

Simple properties will usually be inlined by the optimizer, so in the end there is no performance hit.

Best regards
Espen Harlinn

You have three excellent answers here (all of which got my +5), but I will add an extended comment in regard to your statement that you read ... re Properties ... that you should "avoid setting or getting private fields directly."

I have the feeling that you were reading content in the context of the time when, in .NET, you had to explicitly define the private variable used by a Property. For example

private int _theInt;

public int TheInt
{
  get { return _theInt; }
  set { _theInt = value; }
}

In those times it was considered "bad form" to directly manipulate the private variable _theInt, and definitely 'foul play' to ever make that variable 'public.'

And, of course now, in 'modern C#,' you just write:

public int TheInt { get; set; }

And the compiler generates the (hidden) backing-field for you.

Opinions vary among OO-philes as to what extent processing should be done in the 'get and 'set of a Property. I personally do not like to see the 'get of a Property used as a substitute for a method call, but that's just my personal taste.

... edit ...

For example, here's a comment on computation within Properties in a recent thread on the C# discussion forum by Bob Janova, someone who I regard as one of the most thoughtful and articulate commentators we are lucky to have sharing expert knowledge on CP[^]:

"I rather agree with Davey on the use of properties here – when the values you want to read are uniquely specified by the current state of the object, and reading them has no side effects and does not require extensive processing*, a property is appropriate. As it happens, they are implemented as dynamic calculations, but logically those values are part of the state (you could set them when you modify the state, i.e. the diameter) and so querying them is querying the object state, which is what properties are for.

(*: This is one of those things that, in principle, shouldn't matter, but if you call a property getter you expect that to be almost free in terms of time, so it does. Also, as an aside, I once wrote an XML class which constructed the entire DOM tree when you assigned its Text property. I think that's probably abuse, although the rules for a property setter are more relaxed; setting a property can cause extensive recalculation and side effects such as data binding and screen refreshes.)"