Slow deallocation in debug mode

[dannycat]

Has anyone experienced the problem where large arrays take a long time to deallocate in debug mode. It does not matter whether you step over the the deallocate line or not the program stops for almost a minute before moving on to the next line. This does not occur when running the same executable outside the debugger. One array in particular where this problems occurs is made up of a data structure with allocatable components. I deallocate the whole array (as I have read somewhere that allocatable array components are automatically deallocated). Would there be any advantage to doing this as opposed to explicitly deallocating all the components first and then deallocating the container array? I'd expect deallocating components would take longer.

Is this normal behavior for the debugger?

[phoenix7983]

I'm eagerly watching the development of this thread. Since upgrading to a Vista box a few months ago, I've seen this exact issue, a crippling one in some debug sessions and one that's forced me into some weird optimizations to cope with it. Posting of follow-up information as you learn more would be much appreciated!

[Steven_L_Intel1]

I don't know that we have "clout" here, but we do have contacts. I'll see what I can find out.

[dannycat]

Quoting - Steve Lionel (Intel)

I don't know that we have "clout" here, but we do have contacts. I'll see what I can find out.

Hi Steve,
Have you had the opportunity to speak to your Mircosoft contacts regarding this problem yet? I submitted your C++ example to Microsoft Support about a week ago but have not had any feedback yet (surprise surprise!). You'd think they would want to sortthese sorts of problemsout so more people would consider upgrading to Vista. I heard somewhere thatVista is not selling well). Unfortunately I had no choice of OS when I bought my Laptop and I'm reluctant to change or create a dual boot system in case it creates more problems than it solves.
I assume that thisis no longer considered an "Issue" at Intel.

[jimdempseyatthecove]

Dannycat,

If you are interested in trying to find out what is going on with the long delay, you might be able to do the following:

Download a copy of CodeAnalyst from the AMD website. CodeAnalyst is a profiling product similar to VTune (VTune might be able to do the following too, I know CodeAnalyst will). Although CodeAnalyst is intended for use on AMD processors, you can run timer based sampling.

Setup:

1) Create a program the reads one line of input from the console.
2) Get your application setup to run a debug session and ready for F5 (don't press it yet)
3) run CodeAnalyst, setfor timer based sampling, and set to run the read one line program
(note youwill be managingtwo windows, one for IDE, one for CA)
4) Launch the CodeAnalist profiling
5) Immediately click on the IDE window then press F5 to launch the debug session
6) wait for debug run to finish
7)Click on the console app run by CodeAnalystand press return

Although CodeAnalyst was setup for theone line consol program it will have gathered the data for the application being debugged by the IDE as well. (andeveryting else running on your system).

Examining the CodeAnalyst report might shed some light on the issue.
And then knowing whats going on might provide you with the hints to perform a work around (or find one using Google).

Good luck,

Jim Dempsey

[Steven_L_Intel1]

dannycat, you are correct that this is not an Intel problem. We have not yet been able to get an engagement from Microsoft on this.

Jim, the problem is inside the Microsoft C++ run-time library, which is called by the Intel library. Short of eliminating deallocations from the program, there's not much that can be done here.

[jimdempseyatthecove]

The MS C++ run-time library (or parts of it like free/delete) can be usurped if it is a serious enough problem.

MS allocator/deallocatorhas an option to enable/disable a feature for memory fragmentation. On a whim the user could try flipping it the other way and see what happens.

http://msdn.microsoft.com/en-us/library/aa366750.aspx


Jim

[dannycat]

Here is the reply I finally received from Microsoft suggesting possible work arounds for the slow debugging problem! I have not had chance to try it yet though.

"Thank you for taking the time to file this. Unfortunately it is not an issue that we are able to address, as this is not governed by the debugger, but rather is a behavior of the operating system.

When a process is created under the debugger, the operating system by default uses the debug heap. The debug heap does more verification of your memory, especially at de-alloc.

There are two possible workarounds:
1. Attach to the process soon after startup.
2. Since you are using Intel FORTRAN which is not Microsoft supported, you can try the following, although I cannot provide any guarantee this will work for FORTRAN -Add the setting _NO_DEBUG_HEAP=1 to the environment block of the process via the debugging properties window (right-click the project in the Solution Explorer->Properties->Debugging and add the line to the "Environment" row).
-If that does not work, try opening a command prompt, setting the environment variable _NO_DEBUG_HEAP=1 and then open visual studio from inside that command prompt. All processes created from that instance of Visual Studio will inherit the

Best Regards,
Andrew Hall
Visual Studio Debugger"

I will try option 1 first and will inform the forum if it has any effect upon the run times. In the meantime please fell free to try it out.

I think that the workaround has vastlyimproved the performance of the program. I don't know if any side effects are introduced by adding the Debugger Environment variable though as I'm not sure what it does.

[Steven_L_Intel1]

Very interesting! What this does is, as the MS rep said, disable additional checks that are made to help catch errors such as using pointers after deallocation, buffer overflows, double deallocations, etc. That's what a debug environment is all about, right?

[phoenix7983]

Dannycat,

Thanks for posting the response! It does seem as though the workaround is probably best used "as needed" (i.e., when a specific issue requires it) rather than generally, for the reasons Steve Lionel mentioned. However, for those situations (I'm thinking of a few specific ones I've run into), it will be a lifesaver!