What I like about C# are things like run time reflection (ie: easily determining the type of an object at run time.
Side note: run time reflection has poor performance. Delegates also have poor performance. But, yeah, don't worry about that much.
There are cases where you can write code which is faster without being less readable, and if you know about those you can take them into account when designing something. For example, if you're planning something which you would normally do (numFoos % maxFoos) (modulus), you can swap the slow modulus operation for an extremely fast & operation if numFoos is always positive and maxFoos is (2^n), where n is any positive number. You would & it by 1 less than you would have %'d it by. (numFoos % 4) would become (numFoos & 3), for example.
E.G. Here's an example in javascript (I just copied this right out of what I'm working on at the moment).
var blankSubEntry = (lastWritten[(lastWrittenStart+matches)&maxMatches]==="");
if (hash == lastWritten[(lastWrittenStart+matches)&maxMatches] || blankSubEntry) {
Now normally you might say "well I should store (lastWrittenStart+matches)&maxMatches into a variable and then refer to that" - and that's fine. But hopefully the compiler should be smart enough (but not necessarily with javascript...) to optimize those so that'll only be calculated once anyways. Even if it doesn't, and you do that 5 times, it should still be faster than doing it with % once. (% takes 30-40 clock cycles, IIRC, and & takes about 0.5, in a pentium 4*)
* = I'm oversimplifying how that works. It's actually more complicated than that, and depends on what other operations are being done at the time, and what's going to be done after it, and I don't have a clue how it has changed after the pentium 4 or with AMD CPUs, etc.
So, things I usually do:
1. Prefer & instead of %, and choose power-of-2 sizes for things which will be using it (otherwise we can't use &).
2. For distance checks, omit the sqrt, and premultiply whatever we're going to be comparing against. You can calculate xdist*xdist + ydist*ydist and compare it to somedist*somedist to determine if the distance is <, =, or > than somedist. You can't determine how far apart they are, though. (Sqrt is slow)
3. If doing foo squared, replace with foo*foo (an optimizing compiler might already do this)
4. If doing foo * 2, replace with foo+foo (an optimizing compiler might already do this). Since multiplication (30ish cycles?) is much slower than addition (.5 cycles), you could even do foo+foo+foo+foo if you really wanted to, except that foo << 2 would also work there and would probably be faster.
5. When designing things that will be multiplied or divided by a number, prefer designing them so that you can use power-of-two multipliers/divisors. The compiler might be able to optimize multiplication/division by a constant which is a power of 2 to use << and >> instead, which is faster than multiplication, or you can do it yourself.
I tend to code in an already-optimized-but-readable style, but leave the really heavy optimizations to the compiler (especially with c#). Most of what I do are things the compiler can't or wouldn't be likely to - e.g. it can't change the number of terrain types from 7 to 8 and change the % to & and such without breaking your program, but you can design it better instead.
(In some languages I tend to optimize less. For instance, javascript for firefox extensions. I once tried to determine what was the bottleneck in an extension of mine which ran rather slow on many webpages, only to track almost all of the CPU use into a part of firefox's javascript math crap that I couldn't do anything about. That is, the extension checks the HTML and CSS for a page and reverses colors to change dark-on-light pages to light-on-dark pages. The problem is that for some reason firefox's JS math was terribly slow, and the string to int stuff and vice versa too (which were pretty much required for the extension to work and be useful).)