The speed of Managed DirectX

It seems that at least once a week i'm answering questions directly regarding the
performance of managed code, and Managed DirectX in particular.  One of the more
common questions i hear is some paraphrase of "Is it as fast as unmanaged code?".

Obviously in a general sense it isn't.  Regardless of the quality of the Managed
DirectX API, the fact remains that it still has to run through the same DirectX API
that the unmanaged code does.  There is naturally going to be a slight overhead
for this, but does it have a large negative impact on the majority of applications? 
Of course not.  No one is suggesting that one of the top of the line polygon
pushing game coming out today (say, Half Life 2 or Doom 3) should be written in Managed
DirectX, but that doesn't mean that there isn't a whole slew of games that could be. 
I'll get more to that later.

I'm also asked quite a bit things along the lines of "Why is it so slow?"  Sometimes
the person hasn't even ran a managed application, they just assume it has to be. 
Other times, they may have run numerous various 'scenarios' comparing against the
unmanaged code (including running the SDK samples) and have found that in some instances
there is large differences.

Like I've mentioned earlier in this blog, all of the samples in the SDK use the dreaded
'DoEvents' loop, which can artificially slow down the application due to allocations
and the subsequent large amounts of colllections.  The fact that most of the
samples run with similar frame rates as the unmanaged API is a testament to the speed
of the API to begin with.

The reality is that for many of the developers out there today, they simply don't
know how to write well performing managed code.  This isn't through any shortcoming
of the developer, but rather the newness of the API, combined with not enough documentation
on performance, and how to get the best out of the CLR. Luckily, this is changing,
for example, see Rico Mariani's blog (or
his old blog). For the most part,
we are all newbies in this area, but things will only get better.

It's not at all dissimilar to the change from assembler to C++ code for games. 
It all comes down to a simple question.  Do the benefits outweigh the negatives? 
Are you willing to sacrifice a small bit of performance for the easier development
of managed code?  The quicker time to market?  The greater security? 
The easier debugging? 

Like i said earlier, there are certain games today that aren't good fits for having
the main engine written in managed code, but there are plenty of titles that are. 
The top 10 selling PC games a few weeks ago included two versions of the Sims, Zoo
Tycoon (+ expansion), Age of Mythology, Backyard Basketball 2004, Uru: Ages beyond
myst, any of which could have been written in managed code.

Anyone who's take the time to write some code in one of the managed languages normally
realizes the benefits pretty quickly.