Debugger quite slow stepping over certain statements with arrays

[Christopher_Watford1]

This has been reported in the past, but it appears to still be an issue.

Given some trivial code:

V = MAXVAL(SOME_ARRAY)                  ! SOME_ARRAY(30,30)
V = MAXVAL(SOME_OTHER_ARRAY(1:N)%FIELD) ! N is on the order of 10

Compiled with Visual Studio 2017, Intel Visual Fortran 2018; default options out of the box. Debug configuration. Windows 10 1809, 2x Xeon 4114's, 64G RAM.

Stepping over either MAXVAL statement takes on the order of 40-60 seconds. Visual Studio 2017's diagnostic tools report that the actual execution took between 400-500 ms.

Whereas if you set a break point at the first statement, then use CTRL+F10 to walk the lines, these are nigh instantaneous. This was noted by Jim Dempsey in the original thread.

I've been asked to bring this back up for consideration as apparently our developers have, "conditioned [themselves] to set breakpoints past any such statement when [they are] walking thru."

They are referring to any single statement including a large array being operated on en masse.

It would be good to learn how exactly F10 and CTRL+F10 operate under the hood, because it seems like an optimization should be there for a simple step through.

[jimdempseyatthecove]

Apparently single step (over), steps assembly instructions (over calls) until assembly code indicates change in source line number.

For debugging, a hack you could do, is enable FPP and #define MAXVAL debugMAXVAL, and write an out of line function to perform the MAXVAL. Note, you may need multiple declarations. One that returns a scalar and one that returns an array (a generic interface may work for you).

Jim Dempsey

[andrew_4619]

This problem has been around a long time. I have learned by pain not to single step over large array operations. but it would be nice if there was some option that fixes it as can be really annoying.....

[Steve_Lionel]

Jim correctly describes how the debugger works. My memory was that Microsoft addressed this problem some time ago, but I might be mistaken. In any event, how the debugger steps over statements isn't something Intel has control over.