Executable created with the debug option is slow to start execution

[Jim_A_]

I am developing a small program. I have chosen 'Debug' from the dropdown menu in Microsoft Fortran Visual Studio. When I compile and link the program and then try to execute it in a DOS window, it can take several minutes to start execution. If I execute it again without re-compiling it, execution will start with only a ~10 second delay. If I execute it a third time without recompiling, execution starts instantly. But if I modify the source code, then re-compile and link the first execution of the new executable is again delayed by several minutes. What can I do to make the execution start promptly after re-compiling and linking?

I am using Microsoft Visual Studio Professional 2013, version 12.0.21005.1 REL. I have optimization disabled and inline-function-expansion disabled. I also have 'Generate Manifest' turned off.

I am using a Dell Latitude E5440 running Windows 7/

[Jim_A_]

I would like to add the following to my post. I have Visual Studio Professional installed and I also have installed Intel Parallel Studio XE 2017. Following the notes in "Getting Started" within the Intel Parallel Studio XE 2017, it is my understanding that Visual Studio Professional uses this compiler.

I looked at all the suggestions made for my problem so far and either I am already doing them or I can't do them (as in my computer refuses to accept an upgrade to Windows 10, possibly because I do not have all the admin privileges. I even tried turning off 'Access Protection' and 'On Access Scanner' in McAfee VirusScan Console but this did not help.

[Jim_A_]

Adding to the topic "Executable created with debug option is slow to start execution", I decided to try the "Release" option instead of the "Debug" option and found that the Release version created by the compiler is also very slow to start execution. The start of execution is delayed by several minutes.

[Andreas_Z_]

Hi Jim,
This seems to have little to do with Fortran / VS, but is most likely an issue with your Anti Virus scanning solution and its settings - as you seem to already know. Have you tested it "offline" with the McAfee VirusScan completely turned off? I have experienced delays of starting debug or release runs after a build when my anti virus solution (which is not McAfee) is set to scan new files / new files accessed; however, the delay is usually up to a few seconds, not minutes. So, unless your executable is very large, having to wait for minutes sounds rather odd.

[andrew_4619]

have you tried running the windows performance manager (task manager) to see what is hammering resources during the start delay?

[jimdempseyatthecove]

It does sound like your anti-virus program. I use Avast, and it (default) behaves this way. Although in Avast's case, it will pop-up a little notification box that the scan is taking place. The cure for me is to use their filtering system to disable scans for a specific folder (development) and its sub-folders.

Jim Dempsey

[Jim_A_]

So I have tried turning off my antivirus program and that has no effect on the delayed start of the application that has just been compiled. I then watched the Task Manager and I found that 31%  of memory was being used and 5 to 10% of the CPU time was being used during between the time I hit carriage return to start the execution and the time execution actually started. This delay only happens after I have just compiled the program. If I repeat the execution of the compiled program without re-compiling it, on the first repetition execution starts with a much shorter delay and on subsequent repetitions the program starts instantly. 

With no sign of a big demand on CPU time, I really cannot understand what could be causing the delayed start of execution.

[andrew_4619]

Is the hardrive of page file being thrashed? Faster subsequent runs might reflect that stuff is already cached. Also, in Task manager which processes are using the resource during the delay? 

[jimdempseyatthecove]

What is the size of any new coded generated (executable and/or DLLs created). Andrew may be right with the suspicion that Windows is caching the files after the first run.

Jim Dempsey

[Jim_A_]

My program is a console application consisting of a main program and one subroutine. The executable is 33KB and there are no DLLs. I was experiencing ~2 minute delays in the start of execution when I was developing the subroutine of this program by itself. This subroutine is only 24 lines of code.

[Jim_A_]

Also, I could not discover how to detect if the application was creating virtual memory space on the hard drive for this program. I note that the physical memory was 69% free when the program was running. How does one detect page file thrashing?

[jimdempseyatthecove]

>>How does one detect page file thrashing?

Run the "Resource Monitor"

Jim Dempsey