Unreasonable time initialising arrays whilst in debug mode

[acar]

In developing my application I am often frustrated by the time taken to initialise an array whilst stepping through in debug mode. The following example illustrates the sort of thing I mean (note though that I have not tested this simple program to see that the issue occurs - my application is larger but the example identifies the form of code where this issue occurs):

PROGRAM TEST_BORIS

CALL TEST

END PROGRAM

SUBROUTINE TEST

REAL(8)::BORIS(10,10)

BORIS=0D0

WRITE(*,*)'BORIS IS INITIALISED'

RETURN

END

If, in debug mode, I step past the call to TEST in the main program then BORIS is initialised instantaneously.

If, however, I step into TEST and step through, the IDE takes along time to respond to the initialisation BORIS=0D0.

If, on the otherhand, I put a break at the WRITE statement and run to the break then initialisation is again instantaneous.

I have got used to this undesirable issue (but if I'm feeling a little impatient I must restart the debug session and skip over the initialisation). I wonder if this is a known issue ad whether it might be fixed in future releases?

ACAR

[Andrew_Smith]

It is a known issue with code stepping. Try using "run to" or set a breakpoint after the assignment and use F5. Then it will run at full speed.

It frustrates me too if I accidentally step over an array assignment to a large array. Can you fix this issue please Intel ?

[jimdempseyatthecove]

ACAR,

This is likely on a verylow priority to do list. IMO this should be relatively easy to fix.

When you have a statement that manipulates an entire array, such as your setting to scalar value, the "subscripts" are eminating from values managed by the compiler, and therefore the subscripts cannot possibly be out of range. For these types of statements, the subscript out of range test can be eliminated.
The remaining debug issue would be runtime check for uninitialized variables, and in which case, statements like the above, should simply set all entry flags to initialized. The compiler could have an optimization (for debug mode) whereby (when uninitialized variables test is enabled) it could remember if a variable is initialized (IOW used before initialization at compile tile), and when so, eliminate the code for the test for uninitialized.

SUBROUTINE TEST

REAL(8)::BORIS(10,10)

BORIS=0D0

WRITE(*,*)'BORIS IS INITIALISED'
WRITE(*,*) BORIS(1,1)

RETURN

For the above subroutine compiled in debug mode with subscript range tests and uninitialized variables test should generate no diagnostic code. Whereas

SUBROUTINE TEST

REAL(8)::BORIS(10,10)

BORIS=0D0

WRITE(*,*)'BORIS IS INITIALISED'
DO I=1,100
WRITE(*,*) BORIS(I,I)
END DO

RETURN

Would subscript out of range test only in the do loop

Jim Dempsey

[Steven_L_Intel1]

I thought this had been addressed already. The problem is that when you do a "step", it goes instruction by instruction, and there may be lots of instructions to step over. Which version are you using?

[Jeffrey_A_Intel]

An issue is that the stepping is actually carried out by the Visual Studio debugging engine. That's code written by Microsoft, not Intel. There's probably not a lot Intel can do about it directly.

I can't find the explanation I wrote for this some time ago (this is an infrequently AQ), but it's basically as Steve indicated: the debug engine has to go *branch* instruction by *branch* instruction to see if the branch leads execution to a different line number. The definition of step is roughly "run until you are about to excute an instruction *NOT* associated with the current line." The initialization of ARRAY=value is basically a DO-loop which assigns to each element of the array. All the instructions in that DO-loop are associated with the ARRAY=value line.

As such, the DO-loop probably consists of instructions which increment an index, assign the value to an array element, test the index and then a conditional branch. The debug engine has to interrupt the instruction flow *EVERY TIME* that branch is about to be executed, execute the branch as a single instruction and then determine whether execution moved away from the current line. If it did, the "step" operation is complete; if it didn't, continue execution. That's a lot of work and if you've got a loop with thousands of iterations, this can be very slow.

I suppose there could be some way the debug engine could be taught to recognize this paradigm but that's work Microsoft would have to do.

I often use "run to cursor" to get around this issue.

[jimdempseyatthecove]

Jeff,

Good description of the problem

I haven't experimented with this. I have VS 2005 and I notice in the Options | Environment | Keyboard property, there is a Debug.StepByLine. It has no shortcuthot key associated with it. Debug.StepOver has F10 (Global) shortcut assigned to it. One could experiment with setting a shortcut key for Debug.StepByLine (e.g. Ctrl-F10) and see if this produces the equivilent to: Set break point to next line, Run, remove breakpoint when break at next line.
IOW equivilent to: simulate cursor on next line, run to cursor.

Jim