Imagine my surprise when I found that the Java Performance Tuning newsletter had linked to my blog (see http://javaperformancetuning.com/news/news046.shtml ) and imagine how much more surprised I was when they said this:

...Performance wise this blog on .NET performance by Rico Mariani, one of the CLR architects, shows that .NET still has some way to go in catching Java performance. "Less pointers and fewer virtual methods" to improve performance is not far from saying "program functionally"...

I hardly think that one can make any conclusions about which vendor has the edge in performance from my article on Performance Tidbits.  If I was to summarize my advice in that blog in a few words it would be "don't use OOP features that you don't need."

This is not to say that you should shun virtual functions, inheritance, or other features of modern programming languages.  Far from it, often they not only add clarity and maintainability they also improve performance.  But, as often, I find that people have written their code in some elaborate way when a much simpler model would have been equally servicable and more performant.  Whatever programming religion you may have I think you'll agree that more complex language abstractions do not inherently help your design -- rather each more sophisticated feature starts at a net negative and must somehow earn its way to positiveness with benefits such as clarity, ease of maintenance, performance, and so forth.

So when I say things like "don't use a delegates if regular polymorphism would do" I don't mean that you should avoid delegates I mean that you should not use them if they are overkill.

Now as to having less pointers -- nothing will kill your performance faster that bad locality of reference and nothing destroys locality faster than having datastructures that are a forest of pointers.  I think it's fair to say that there are no compilers that can save you from a bad datastructure.  On prevelant processors pointer proliferation is problematic (say that 5 times fast) .  It matters not which flavor of infrastructure you prefer.

Although my experience on other managed systems is much more limited, my impression, and the general feedback, has been fairly consistent that my advice with regard to the .NET framework is usually equally applicable to other managed systems.

I see no Kryptonite here :)