static string _backing; // Backing store for property
static string Property  // Getter and setter
{
    get
    {
        return _backing;
    }
    set
    {
        _backing = value;
    }
}
static string Field;    // Static field

public FieldPropertyTest(Game game)
    : base(game)
{

    long[] results1 = new long[10];
    long[] results2 = new long[10];

    Property = "string";
    Field = "string";
    const int m = 1000000;
    for (int x = 0; x < 10; x++) // Ten tests
    {
        Stopwatch s1 = new Stopwatch();
        s1.Start();
        for (int i = 0; i < m; i++) // Test property
        {
            Property = "string";
            //if (Property == "cat")
            //{
            //}
        }
        s1.Stop();
        Stopwatch s2 = new Stopwatch();
        s2.Start();
        for (int i = 0; i < m; i++) // Test field
        {
            Field = "string";
            //if (Field == "cat")
            //{
            //}
        }
        s2.Stop();
        results1[x] = s1.ElapsedMilliseconds;
        results2[x] = s2.ElapsedMilliseconds;
    }
}

The results:

Get:
Property: 341 ms
Field: 307 ms

Set:
Property: 85 ms
Field: 66 ms

This performance difference from the more robust .NET CLR used in Allen's tests is owing to the fact that the .NET Compact CLR (which the Xbox 360 uses) doesn't inline functions at all -- to my knowledge.

Of course, the small size of the numbers above is good news -- it took 10 million gets on a field to produce a 34ms difference.
It's hard to imagine a scenario where using a field in place of a property would be a relatively large enough performance gain to affect your framerate.

There are also the usual caveats with micro-benchmarks like these, and the difference may be smaller (or larger) than what you see above, in real-world uses.

So, I'd take Jeff Atwood's advice and simply always use (auto-)properties, unless you have a very tight performance sensitive loop that is accessing many properties.

Edit:
The NetCF team blog states that getters/setters are inlined, which is probably a source of some confusion. It's also possible that my results above are wrong, if I've fallen into a micro benchmarking trap. Let me know if you find some results opposing what I've written above.

effectDrawBlock.Begin();
foreach (EffectPass pass in effectDrawBlock.CurrentTechnique.Passes)
{
    pass.Begin(); 

    gd.DrawIndexedPrimitives(PrimitiveType.TriangleStrip, 0, 0, 35, 0, 70); 

    pass.End();
}
effectDrawBlock.End();

When you use a foreach over an array of ints, you will not create garbage, and it’s fast, so that’s perfectly okay.

However, in the above code, “EffectPass pass in” creates a managed effect pass object, used to iterate through the collection. That object then needs to be handled by the garbage collector later.

The fix is to use a for loop when iterating over non-primitive types.
In my case, by changing my code to something more like what you see below, I was able to reduce the number of managed objects generated by my code from 2500/sec to 200/sec as measured by the XNA Framework Remote Perf Monitor.

effectDrawBlock.Begin();
for (int i = 0; i < effectDrawBlock.CurrentTechnique.Passes.Count; i++)
{
    effectDrawBlock.CurrentTechnique.Passes[i].Begin();

    gd.DrawIndexedPrimitives(PrimitiveType.TriangleStrip, 0, 0, 35, 0, 70);

    effectDrawBlock.CurrentTechnique.Passes[i].End();
}
effectDrawBlock.End();

It turns out that this code was generating 7400 managed objects per second:

            text[0] = "FPS: " + fps.FPS.ToString();
            text[1] = "charPos: " + charPos.ToString();
            text[2] = "tLOD: " + tLOD.ToString();
            text[3] = "tTris: " + tTris.ToString();
            text[4] = "tBlocksDrawn: " + tBlocksDrawn.ToString();
            text[5] = "tBlocksCulled: " + tBlocksCulled.ToString();
            text[6] = "drawCodeTime: " + drawCodeTime.ToString();

A complicated optimization for code that isn’t even going to get compiled into the release build would be silly. The easiest fix here is to only periodically update the content of these strings (say, once per second, instead of once per frame.)
Also, some of the garbage generation could be reduced by separating the arrays into one array for the static strings “drawCodeTime: ” for example and then drawCodeTime.ToString() in a separate string. That would still leave thousands of objects per second created, sadly.

If you have a game that relies on many string conversions, your best bet is to use StringBuilder objects (which have predefined size) and replace subsections of those strings with the new string using the .Replace method that StringBuilders have built-in.

To create a custom content processor that will permit you to convert any Texture2D compatible input format into an Alpha8 format texture, do the following:

Right click your game solution -> add new item
Under XNA 3.1 select Custom Content Pipeline, and replace the default class in this solution with this code:

using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.Xna.Framework.Content.Pipeline;
using Microsoft.Xna.Framework.Content.Pipeline.Processors;
using Microsoft.Xna.Framework.Content.Pipeline.Graphics;
using Microsoft.Xna.Framework.Graphics.PackedVector;
using Microsoft.Xna.Framework;
using System.ComponentModel;

namespace ContentPipelineExtension1
{
    [ContentProcessor]
    [DesignTimeVisible(true)]
    class HeightMapTextureProcessor : ContentProcessor
    {
        /// 

        /// Process converts displacement maps to Alpha8 textures.
        /// 
        public override TextureContent Process(TextureContent input,
            ContentProcessorContext context)
        {
            // Convert to data that we can work with:
            input.ConvertBitmapType(typeof(PixelBitmapContent));

            // Select first mipmap, there should only be one:
            MipmapChain mipmapChain = input.Faces[0];

            // There should only be one bitmap, but it doesnt hurt to write this loop:
            foreach (PixelBitmapContent bitmap in mipmapChain)
            {
                for (int x = 0; x < bitmap.Width; x++)
                {
                    for (int y = 0; y < bitmap.Height; y++)
                    {
                        Vector4 pixel = bitmap.GetPixel(x, y);

                        // Move R channel to A channel:
                        bitmap.SetPixel(x, y, new Vector4(0, 0, 0, pixel.X));
                    }
                }
            }

            // Alpha8 contains values from 0 - 1 in the W channel.
            input.ConvertBitmapType(typeof(PixelBitmapContent));

            input.GenerateMipmaps(false);
            return input;
        }
    }
}

Now add a reference to your CustomContentPipeline1 solution in the “Content” module in your game solution.

Right click on the heightmap file(s) that you wish to be converted to Alpha8 and select the HeightMapTextureProcessor as the content processor.

That’s it!