Extreme slowdown when debugging .NET code

Hi, I'm experiencing huge slowdown when I try to debug a .NET-code in VisualStudio. After I set a breakpoint in a subroutine, which is relatively large, VisualStudio hangs for 4-5 minutes (Message: VisualStudio is busy) before values get loaded and I can continue working. This makes debugging almost impossible. Interesting is that when I set a breakpoint in subroutine, which is relatively small, values are loaded almost instatly. There is definitive a connection to the subroutine size. Is there any way to avoid this problem - maybe some debug switch while compiling/linking or something similar? I work on Win-7 and VisualStudio 2008.

If you are using CHECKMATE then try reducing to DEBUG.

What do you mean by 'try reducing'? What should I reduce?

I compile with following switches:

/NO_BANNER /DEBUG /UNDEF /CHECKMATE /FULL_DEBUG /BOUNDS_CHECK /F2K /WIDE_SOURCE /STANDARD_ERROR_REPORTS /SINGLE_THREADED /FPP /IGNORE 179 /CLR /CLR_VER 2 /VS8 /DELETE_OBJ_ON_ERROR /ERROR_NUMBERS /UNLIMITED_ERRORS

Reduce the checking options by using DEBUG but not CHECKMATE not UNDEF and not FULL_UNDEF.

Avoiding those 3 switches doesn't really help, even when using only /DEBUG it still takes way to long. It seems that the delay is caused by loading variable values into memory. Any other advices?

No not really. Problems of this kind are usually only resolved by the 'binary chop'. That is reducing the code until the problem goes away then building slowly back up until the problem is localised.

Hm, I guess you imply that a certain line of code is causing the slowdown. In my opinion it is simply the large amount of data, since I experience the same problem in several FTN-programs. As soon as the routine gets 'rather large’ slowdown appears. One more thing: while waiting for Silverfrost to make FTN Win-8 capable, we were forced to rebuild one of our programs so that it works as a COM-server (with another Fortran compiler), so I can now compare more or less the same code which in one case works in .NET-environment (FTN) and once as COM (alternative compiler). I can definitely confirm that this debugging slowdown problem appears only with FTN. I cannot say if this is a .NET issue or general FTN issue, but it apperas only in this combination.

Would you say the slowdown is related to the amount of code in the project or the amount of data?