I believe you can set the optimization settings of specific files in the Visual Studio properties, so you can turn all optimizations on in one file and leave them off in the others. If that's not granular enough you can use the #pragma optimize (https://msdn.microsoft.com/en-us/library/chh3fb0k.aspx) option but that's kinda yucky.

As far as I know, no. But there are various debug settings and optimization settings you can adjust. I'd suggest trying with optimizations enabled, but debug symbols still intact.

If this is c++ set your solution to release and warp parts of the code that you want in debug in pragma optimize. Look at MSDN, GCC or Clang docs for the precise syntax because it is compiler dependant.

For MSVC

#pragma optimize( "", off)
//Code in here is not optimized.
#pragma optimize( "", on)

This is not the same as running a release build with debug symbols, the code in the wrapped pragma is actually compiled as un-optimized code, like a debug build. This makes debugging easier. Sometimes you need to do this with whole files because inline functions and stuff like that.

Of course you can. This is often called a "hybrid" build.

I wouldn't start there, though. There are many semi-secret tricks to make debug-friendly builds much, much, MUCH faster:

1) Disable iterator debugging and similar checks; it's different for every library vendor, but that link covers Microsoft's. This can make a MASSIVE difference in debug speeds if you use the vendor-supplied STL in your code.

2) Disable excessive runtime debug checks in your builds, e.g. /sdl- in Microsoft's compiler.

3) Enable inlining of small functions, e.g. /Ob1 in Microsoft's compiler. This has minimal negative impact on debugging quality but makes for a MASSIVE speedup in runtime for C++ apps, especially those using a lot of accessor functions or smart pointers. "good" C++ code is very, very heavily dependent on inlining.

4) Avoid vendors' slow memory allocators, e.g. disable Microsoft's debug heap. If you're making the mistake of hitting the vendor-supplied system allocators much you can end up slowsville.

The additional optimizations employed in Release builds honestly account for relatively small gains compared to any single one of the above in most real-world projects.

Do those and debug builds of a big AAA game engine might run in a steady 60 FPS with full physics and AI and crazy graphics effects; forget to do those things and a small little indie 2d game can fail to run at a steady 20FPS in an empty level.

The exact flags and steps on other compilers are different. Consider -Og on GCC for instance.

Also, you can just debug release builds. Microsoft has the /Zo flag that makes debug information in optimized builds much better, for instance.