forums.silverfrost.com

gperiskic · Joined: 18 Dec 2009 Posts: 34 Location: Stuttgart, Germany

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.

PaulLaidler · Posted: Thu Jun 13, 2013 4:01 pm Post subject:

If you are using CHECKMATE then try reducing to DEBUG.

gperiskic · Joined: 18 Dec 2009 Posts: 34 Location: Stuttgart, Germany

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

gperiskic · Joined: 18 Dec 2009 Posts: 34 Location: Stuttgart, Germany

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

PaulLaidler · Posted: Thu Jun 13, 2013 5:22 pm Post subject:

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

gperiskic · Joined: 18 Dec 2009 Posts: 34 Location: Stuttgart, Germany

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?

PaulLaidler · Posted: Fri Jun 14, 2013 7:01 am Post subject:

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.

gperiskic · Joined: 18 Dec 2009 Posts: 34 Location: Stuttgart, Germany

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.

Robert · Joined: 29 Nov 2006 Posts: 457 Location: Manchester

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