R – Did Visual Studio 2008 SP1 introduce runtime bugs or am I crazy

openmpperformancetbbvisual-studio-2008-sp1

I've been wracking my brains out trying to figure out what the heck is going on with the most recent (non beta) Visual Studio 2008 SP1:

My app built with OpenMP runs incredibly slow in the debugger, bringing CPU usage to 100%. When they are run outside the debugger, it merely runs slowly (for a release build).

My app built with the Intel Thread Building Blocks library, or my own thread team implementation, runs slower in the debugger than when run outside the debugger (for a release build).

When I go to my other development machine, which has not had SP1 installed, the situation is different. Running in the debugger, or outside, has no effect on program performance. OpenMP accelerates my application, as does Thread Building Blocks or my own thread team code (written hastily out of exasperation to figure out this problem).

This is with absolutely no changes made to the app, just run it inside, or outside, of the debugger, SP1 versus regular Visual Studio.

I have found nothing about this on Google so I am sticking my neck out and saying something in the hopes that someone else might recognize this is happening to them. Either that, or I am seeing things.

Best Answer

Yes. In certain cases. We experienced a similar situation of extremely slowdown after switching to SP1. The cause of this was exceptions. We had a datamodel that made a lot of use of a pattern of trying to access keys in a dictionary, having it fail, and catching the exception:

try {
  var a = dict[key];
} catch(KeyNotFoundException) {
  dict[key] = default;
  a = default;
}

This is just an example, but the cause was any exception at all. For whatever reason, VS, in the debugger only, is extremely slow. Note, this was the case before, but it was significantly worse with the new patch.

The solution is to simply always use a test. for the dictionary example above, use the .TryGet or in custom code check if your call will generate an exception before calling it, if it's something that will happen a lot (thus is an 'expected' thing instead of an 'exceptional' thing).

More Info: Exceptions and Performance

Related Topic