High background (?) activity during debugging

[jirina]

I am debugging an application using Parallel Studio 2016 Professional in Visual Studio 2010 Professional SP1 on Windows 10 Professional 64-bit. The problem is that making a single step for simple commands takes too much time.

After pressing F10, the mouse pointer changes to the one indicating background activity. This indicator is not displayed continuously, but it flickers and changes to the standard pointer and back very quickly multiple times. This is proportional to the number of watched variables and increases time needed to make a single step to an unpleasant value that requires waiting for the background activity to be finished.

I have 5-10 scalar variables (integer, logical, real) and about 10-15 arrays (2D), usually only their parts containing up to 20 elements in the Watch window(s). Some of the array are from modules that are not used in the debugged subroutine, so I have something like Module::Array(i1:i1,j1:j2) in Watch. Is this too many variables whose updating needs so much time that it makes one debugging step unpleasantly long? I tried removing all watech variables and making steps is normal.

I tried removing those variables that are taken from modules that are not used in the debugged subroutine, and the problem persists. I have only 6 scalar variables and parts of 3 arrays, with about 50 elements in total! Debugging a complex problem requires more variables to be watched, however making steps is then very slow and time consuming...

[jimdempseyatthecove]

If you have the runtime check for "array index out of bounds" enabled, and if you single step over a line that performs an array (or array section) equate, then you will see this behavior (as it test each index during the =). You can avoid this by right-clicking on the next line and choosing "Run to cursor" (or set a break point at the line following the =).

Jim Dempsey

[andrew_4619]

@Jim I see that problem also and use that workaround but I didn't know it was array bounds checking that caused it. Useful info thanks.

[jirina]

I had the compiler option /check:bounds enabled, so I tried disabling it and the problem is still the same.

It does not matter what line I step over - the problem occurs even if the line contains e.g. a simple value assignment like var = 0. The problem thus does not seem related to the fact whether the line stepped over does something with an array or its section.

Running to a cursor shows the same behavior, but I only have to wait once for whatever in the background needs to finish. However, running to a cursor cannot be used in the code where I need to go line by line and see what happens.

[jimdempseyatthecove]

The second cause that I have found is less prevalent and is a Visual Studio issue. Try issuing from a command prompt

devenv /ResetSettings

*** while in the directory of the devenv that launches the VS version you use.

You will have to see where your VS is installed, and then find devenv.exe

Note, this will also reset any customizations you may have set for your IDE. If you have any customizations, I think there is an export for those customizations.

When I first encountered this, I though VS crashed as it took literally minutes to perform the step.

Jim Dempsey

[jirina]

I exported my settings, started VS from command prompt from the directory with devenv.exe, with the option /ResetSettings. Debugging then works very well.

Importing the exported settings brings the problem back, so I tried starting from default setting and I changes colors manually instead of importing settings from a file, and the problem is back again. I will probably have to give up my favourite colors to make degugging work without lags.

Edit: 

Thank you for your kind help so far.

[Kevin_D_Intel]

Can you please point me to where you changed the colors manually and what changes you made so I can try reproducing this issue?

Thank you.

[jimdempseyatthecove]

jirina, In my case, I wasn't changing colors. In fact, I do not recall making any changes to the IDE preferences. Prior to finding the devenv /ResetSettings, my work around was to recreate a solution+project. This was a real PIA. Giving Kevin the hints necessary to reproduce the problem would be helpful as he would have better contacts with MS. I do not know if this is an IFV integration issue with MS VS, but I do know the VS issue was reported back as early as VS 2005 and non-IFV. Look at the bottom of http://stackoverflow.com/questions/15640883/application-error-visual-studio-keeps-crashing

This has a hint on how to isolate the problem (I haven't tried this).

Jim Dempsey

[andrew_4619]

I used to get VS grinding to a halt due to the VS SU0 file becoming huge due to it replicating  bookmarks each time it was opened/closed. It is always worth keeping an eye on SU0 the file size. Bote: I just checked a VS2013 solution and it seems theat SU0 is not used anymore the a .db3 seems to be the one now....

.

[jirina]

I have to apologize - my conclusion that customizing colors is causing the problem was wrong. I did not realize that the Watch window is not shown after resetting settings. I did the reset again, did no customization, and making steps is OK as long as neither Watch nor Locals window is not shown.

The problem is more obvious with the Locals window where usually more variables are listed than in the Watch window.

I am sorry for wasting your time on the customization; at least we know the problem is still there with default settings for the Visual Studio environment.

I tried renaming the Visual Studio folder with settings and letting VS to re-create this folder again, but this did not bring any change. I combined this with devenv /ResetSettings.

After resetting VS settings, without any changes to them, I re-created the solution and the project. The problem is still the same - the more parameters are watched, the longer it takes to make a single step - there seems to be a background activity going on for each of the watched parameters (if they are arrays, then for each of their elements).

[jimdempseyatthecove]

The Watch Window with an array may be calling the array bounds checking code if the check bounds is enabled. If it is, then this something that ought not to be done as the array extents are directly obtained from lbound and ubound for each DIM= and thus cannot possibly be out of range.

Are your arrays in expanded view? (IOW showing content, not {...})

Jim Dempsey

[jirina]

Disabling /check:bounds makes no difference.

What helpes a little bit is to change the expanded view of arrays to the collapsed one. This makes stepping through the code faster, but the problem still persists. In addition, collapsed arrays do not make sense for me - I am watching what is happening with them.

[jimdempseyatthecove]

Jirina,

Not that you would want to debug this way, as a means to help convey where the potential problem is located, what happens if you present only one source code window with just a few lines (5). IOW reduce the amount of cosmetic touchup that the IDE has to do to establish its viewpoint.

Are you remote debugging and/or are source files located on a remote system?

Can you post a full-screen screenshot? You can edit the .jpg with Paint to redact proprietary information yet keep the essentials of your IDE configuration.

Jim Dempsey

[jirina]

Jim,

I reduced the source code windows to just the one where I am making steps, I also changed the size of the VS window in such a way that it only shows several lines of the source code, and I removed all arrays from the Watch window and I have only 7 local, scalar variables in it. The problem is the same; of course, not so serius like in the case with more watched variables including arrays.

A screenshot of the VS window is attached.

I am going to try the same on my older computer with Windows 7 Pro, but it will take some time.

[jimdempseyatthecove]

I see you have 4 watch windows specified. Is the slowdown proportional to the number of watch windows?

The Call Stack window could present some lag time when your call stack is deep and your symbol files are located on a remote system.

Other than this (last) two areas to look at, I am running out of suggestions.

Jim Dempsey

[jirina]

Jim,

The call stack is not deep in my case - it is up to 5 level, which I think should be OK.

Symbol files are not located on a remote system, so even this is not causing the problem.

Finally, I do not have any variables in other Watch windows, and even if I close all of them but the first one, the problem is the same.

Thank you once more for all your suggestions; I appreciate your time and effort. I will have to cope with the situation and hope that an update of Parallel Studio, possibly also Windows 10, will resolve the problem.

[jirina]

I have just installed Update 1, hoping that the problem would be resolved, but it is not.

I have one allocatable 3D array in Watch 1, showing only its part, e.g. Array(I,J,:), which can be about 30 elements. Making one step with this Array in the collapsed state changes the mouse pointer to indicate a background activity for about 0.5-1 seconds, while it is almost 2.5 seconds if array elements are shown, irrespectful of what the step is doing (it can be anything unrelated to the watched array).

Could anyone from Intel comment on this? Is there any check or update of array elements going on? And should it take so long? I am trying to watch complex changes and I need to see how anything between 10-40 array elements are changing. If a single step takes 2 seconds, debugging becomes annoying, because I need to wait for the update or whatever it is to finish to see what was changed and how...

[Steven_L_Intel1]

When you step over a statement, the debugger is actually single-stepping instructions until it gets to an instruction that belongs to the next statement. For some array operations this can be a LOT of instructions. Try this instead - set a breakpoint on the next statement and press F5 - is that faster? We don't have much control over what happens in the debugger - the debugger will call us to evaluate expressions, but we can't control when that happens.

[jimdempseyatthecove]

As an alternative to walking the break point, you have an additional option of Right-Clicking on the line you wish to break on, and then selecting Run To Cursor.

On my VS (I haven't added hot keys), F4 and F8 both perform the same function

Edit.GotoNextLocation

If this is the case for your setup, you can change F8 to Ctrl F10 (run to cursor). This will alleviate using both hands or multi-click. Depending on your mouse, if it has additional buttons, you can program one of them to "Run to cursor". Then your only issue is assuring the cursor is on the correct line.

Jim Dempsey

[jirina]

If I set breakpoints to certain locations in the code and press F5, or if I press Ctrl+F10 to run to the cursor position, the behavior is the same - if the breakpoint/cursor location is reached, the background activity begins, taking more time if the view of a 3D array part is expanded.

I understand there can be a lot of instructions for array operations; I only read or modify one element at a time.

Running accross those lines that do not do anything with any of the 3D arrays results in the same "problem" - once a breakpoint or a cursor location is reached, it feels like all elements in the Watch window are somehow updated (the background activity cursor is "flickering", and the number of "flickers" seems propotional to number of displayed elements), even though this does not seem to be necessary as none of the 3D fields is being modified or even worked with.

[jimdempseyatthecove]

One other thing to try is to futz with VS InteliSense.settings. Google search for "Visual Studio InteliSense slow" and you will get some suggestions.

https://forums.unrealengine.com/showthread.php?2355-Visual-Studio-2013-Intellisense-is-REALLY-slow

http://www.codeproject.com/Tips/350495/Visual-Studio-WAS-painfully-slow

There are many others. The second one looks counter-intuitive.

Jim Dempsey