Tom has the final(?) say on the matter.... Or is it? Of course its not :-) Rick has added a response including some perf and memory numbers.

I figured I should put a quick summary list together that explains some of the history behind this.

• Tom started the discussion in November 03 with his Render Loop post where he highlights the high memory allocations that happen using the .DoEvents method.
• He followed up the same month with Render Loop Revisited where he briefly discusses some alternatives.
• A brief mention in his Speed of Managed DirectX post points out that even though the samples use .DoEvents they still run with similar framerates as the unmanaged samples
• Jump forward to June 2004 with Renderloop re-Revisited where he talks about the change in the summer 04 framework to use PInvoke and not .DoEvents
• March 2005 and Rick comes up with what he considers to be the Ideal Managed render loop.
• March 2005 (again). Rick decides that there was a bug in his previous solution and posts an improved version
• May 2005. Tom puts it all together, makes some small changes and puts the result into the upcoming June SDK.
• May 2005 (again). Rick comments on Tom's final solution and adds perf and garbage collection numbers.

My opinion, and as with all free advice you get what you pay for, is that for the kind of projects most of us are working on it really doesn't matter. Pick one and go with it. The memory allocations with .DoEvents are high but its all going to be generation 0 garabage collected anyway, you are much more likely to screw up something in your own code that causes worse memory issues. As for the increased framerate - unless you are a computer graphics genius there are likely to be algorithmic issues to do with your rendering that will dwarf the effect that the render loop has.