Slow attachment of VS

[Andrew_Smith]

When I am attaching Visual Studio to an exectuable for debugging it take about 8 seconds to attach with VS2008. With VS2005 it was less than 1 second. Since I have to frequently attach and detach, this delay is causing me loss of productivity. Is it something to do with Intel's VS integration or should I persue Microsoft for a fix?

The executable I am attaching to is written in Smalltalk and does not have debug information. It the the Fortran dll's that I am debugging.

[Steven_L_Intel1]

I can't think of a way that the Fortran integration would affect this, but you can try as an experiment doing a "Change" on Intel Visual Fortran and removing the IDE integration, then seeing if the problem persists.

Let me suggest, though, a better way to approach this. Rather than use the "attach to process", right click on your DLL project, select Properties, Debugging. For Command, enter the path to your Smalltalk executable, or whatever program you launch to run the program. Set a breakpoint in the DLL routine(s) and then press F5 to start under the debugger. The executable will launch and, when it gets around to calling the DLL, it should stop at the breakpoint.

[Andrew_Smith]

Quoting - Steve Lionel (Intel)

I can't think of a way that the Fortran integration would affect this, but you can try as an experiment doing a "Change" on Intel Visual Fortran and removing the IDE integration, then seeing if the problem persists.

Let me suggest, though, a better way to approach this. Rather than use the "attach to process", right click on your DLL project, select Properties, Debugging. For Command, enter the path to your Smalltalk executable, or whatever program you launch to run the program. Set a breakpoint in the DLL routine(s) and then press F5 to start under the debugger. The executable will launch and, when it gets around to calling the DLL, it should stop at the breakpoint.

I have since spotted several reports of slow symbol loading for VS for various reasons and I will investigate these as well as your suggestion of testing removing IVF integration.
It would use up more time to restart my applicationsince the application is a large Smalltalk development image that would need to be saved in order to close it and then starting it takes a few seconds too. I normally leave it open and ask it to close any dll's that I need to re-compile.

[Andrew_Smith]

Quoting - Andrew Smith

I have since spotted several reports of slow symbol loading for VS for various reasons and I will investigate these as well as your suggestion of testing removing IVF integration.
It would use up more time to restart my applicationsince the application is a large Smalltalk development image that would need to be saved in order to close it and then starting it takes a few seconds too. I normally leave it open and ask it to close any dll's that I need to re-compile.

I found out what makes VSslow to attach. I had about 25 breakpoints on some test code detecting bad things. When I deleted all my breakpoints, VS attached much faster (in about one second). Maybe I will replace the breakpoints with some code that causes a runtime error. It wont be as convenient since it can not continue after that. Are there any runtime warnings I could trigger that are continuable?

[Steven_L_Intel1]

Try the Win32 API routine DebugBreak.