The point made by frob about languages that are considered 'slow' is definitely a valid one. There is nothing forcing a C# programmer to use every available component from every possible feature set. This is where the performance issues come about. Not every available function was designed for a games and, no doubt, some should be avoided where speed is an issue. On the flip side of this, a sloppy coder could easily make a huge mess using a language that is considered 'fast' such as assembly, if you write inefficient code your program will be slow regardless of your choice of language. If this is a concern for you then make sure that code optimization is a focus in your research as much as anything else. Personally, I like plain old boring C for the runtime software, but this is arguing semantics, I try to only use what is common to every C-based language. Because of this, last year when I decided to rebuild my engine to work on iOS it was almost perfectly seamless, I never even bothered learning the Objective C standard and everything went fine because, as I said, I try to only use what is common to almost every language.
If you are really concerned about performance than you might consider studying as many languages as you can stand to, at least to start off with, and this way you'll start to see the pattern that is common to all, then you will naturally fall into the environment that you are best suited to. This will help you to avoid dead-ends down the road like the one that's worrying people who have been using XNA although this XNA issue doesn't sound as bad as people have been saying but this scenario is still very possible. All it takes is for one CEO and his board to bankrupt a corporation and you may find the development environment of your choice is gone the way of the dinosaur. You can future proof yourself by avoiding what is not common to all.
If you must use inefficient libraries, try to keep it out of the main game executable and only use them for pre-processing stuff like code generation, model formatting, level building and other such things. I love fstream.h and I use it constantly for code generation and diagnostics, but I'd never use it in the game itself, accessing the hard drive is at least a couple hundred times slower than the rest of the computers components.
Until you start writing in-depth physics simulations, the graphics pipeline is likely going to be the only bottleneck you face for now. Here are some optimization guides for OpenGL and DirectX. Most of these tips are common to both since the GPU is ultimately where graphics calls go. If you get this stuff right then you'll be ahead of the game.
Here's one for AMD CPU's http://support.amd.com/us/Processor_TechDocs/47414_15h_sw_opt_guide.pdf
And one from Intel http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf