| Author |
 Topic  |
|
|
dcastonguay
Senior Member
Canada
32 Posts |
 Posted - Sep 28 2023 : 4:31:21 PM
|
Hello,
For a while now, I've experienced an issue when using Alt+G (VAssistX.GoToImplementation) after changing the caret position or the selected word in the Text Editor (in C++).
Let's say I put the caret on a symbol "S1" in file A, then hit Alt+G: this opens file B and properly locates the symbol "S1". So far so good.
However, it happens very often that if I go back in file A, then move the cursor to another symbol "S2", then hit Alt+G again, Visual Assist still opens file B and locate "S1", instead of locating "S2". Even if I go back to file A again, and move the caret again on "S2" (or select the whole symbol "S2"), and hit Alt+G again, Visual Assist keeps locating "S1" instead, and does that for a while (at least several seconds). At some point, after repeating the process multiple times (or simply waiting for a while before trying again), Visual Assist properly locates "S2". If I then try the same with a symbol "S3", the issue occurs yet again.
I've seen this behavior happen for at least 6 months now, at least since the following version, on Visual Studio 2019: "VA_X.dll file version 10.9.2471.0 built 2022.11.25". I am currently using the following version, and the issue still occurs:
"VA_X64.dll file version 10.9.2502.0 built 2023.09.07
DevEnv.exe version 17.7.34031.279 Professional"
I _think_ the issue didn't occur on Visual Studio 2017 (but I also switched codebases when I switched to VS2019, so maybe that's also part of the issue).
For context, our solution has 84601 files (as reported by the "Open File in Solution" dialog). I suspected the issue could be caused by the "Parse all files when opening a project" option, so I tried with this option both checked and unchecked, and the behavior still occurs.
Is this a known issue? Could there be a workaround? Are there some specific options which could help mitigate the issue?
Since Alt+G is a very useful feature, it can be very annoying when it doesn't work as expected. :)
Thanks! |
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Sep 29 2023 : 08:23:38 AM
|
Definitely not a known issue, no.
When you are seeing this, can you please place the keyboard caret into one of the new variables, and then look at VA's Context and Navigation fields. These are normally found at the top of the editor window and are where the Alt-M list appears from.
What, if anything, is being shown here? They should update nearly instantly when you move the caret into a new symbol, and should show details about this symbol. If VA isn't picking up that the keyboard caret has moved to a new symbol then this would explain the problem, but not tell us why it is happening.
Are these symbols in the same function, or in different functions?
If you look at the Alt-M list or VA Outline, does VA seem to understand your code correctly? Or are you seeing signs of parser problems? |
zen is the art of being at one with the two'ness |
 |
|
|
dcastonguay
Senior Member
Canada
32 Posts |
Posted - Sep 29 2023 : 09:51:20 AM
|
Hello,
Thanks for replying.
> When you are seeing this, can you please place the keyboard caret into one of the new variables, and then look at VA's Context and Navigation fields.
> What, if anything, is being shown here?
Indeed, I was able to reproduce the issue by just quickly selecting two symbols in the same function alternatively for a while. The bars at the top update properly for at first, then at some point, there is some processing going on that seems to delay the update of the bars, and if I Alt+G at that moment, I am not taken to the right definition. During the delay, the status bar at the bottom says "VA: Parsing <some_path>...".
In my contrived test, the delay is not very long, but in real cases (in bigger/more complex files, maybe), the delay can be multiple seconds.
I have a made a quick video of the issue, but I don't exactly know how to post it here.
> Are these symbols in the same function, or in different functions?
Most often, I see the issue with symbols in the same function (e.g. Alt+G on a symbol, it works, use the mouse "back" button to come back to the original code, select another nearby symbol, Alt+G again, and it doesn't work).
> If you look at the Alt-M list or VA Outline, does VA seem to understand your code correctly? Or are you seeing signs of parser problems?
At least according to the Alt+M list, VA seems to understand the code correctly.
Thanks for looking into this with me! |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Sep 29 2023 : 10:33:39 AM
|
Are you currently working with:
VA Options -> Performance -> Parse all files when opening a project
On or Off?
You have a good number of files in your solution, but not a scary number.
Are you working with a solution, or are you opening a directory, probably working with CMake in this case?
The fact that VA is off parsing a file would explain why it is slow to work out you have moved to a new symbol.
For the video, the simplest solution is to try and send it to:
[email protected]
including this thread ID or URL in the description, so we can match it up. Then its just a question of file size for email. |
zen is the art of being at one with the two'ness |
|
|
|
dcastonguay
Senior Member
Canada
32 Posts |
Posted - Sep 29 2023 : 11:10:41 AM
|
> Are you currently working with:
> VA Options -> Performance -> Parse all files when opening a project
> On or Off?
At the moment, it is On, but I've seen the issue with it Off.
> Are you working with a solution, or are you opening a directory, probably working with CMake in this case?
I'm working with a solution.
> The fact that VA is off parsing a file would explain why it is slow to work out you have moved to a new symbol.
But I'm curious to know why it starts parsing stuff while I'm just alternating the cursor between two symbols... but maybe it's a recurring background job.
> For the video, the simplest solution is to [...]
Sent the video.
Thanks!
P.S.: On an unrelated note: is it normal that I wasn't auto-subscribed to this thread when I created it? I was expecting to receive e-mail notifications, but I didn't (I just manually subscribed, so that should be fixed).
|
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Oct 02 2023 : 12:36:55 PM
|
I have the video, many thanks for this, and I have replied via email for ease:
case=150099
As for the forum and email, I am not sure, but I suspect this was set as a default to stop people being bombarded with email. |
zen is the art of being at one with the two'ness |
|
|
|
dcastonguay
Senior Member
Canada
32 Posts |
Posted - Oct 03 2023 : 3:40:47 PM
|
| I've re-replied to the email with an additional video using an open source codebase. I'm posting here just to make sure you received it properly (I replied yesterday); maybe the video was too big or something. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Oct 04 2023 : 09:49:37 AM
|
| Apologies for the slow reply, I have just replied to your email. I did get the video, but was busy working on other problems. |
zen is the art of being at one with the two'ness |
|
|
|
dcastonguay
Senior Member
Canada
32 Posts |
Posted - Oct 04 2023 : 2:00:43 PM
|
I'll reply here so that the information becomes publicly available (if it isn't already).
I wanted to install Visual Assist in an Experimental Instance of Visual Studio (I had already managed to do this in the past). However, I can't seem to find the way I managed to do this anymore... do you have instructions somewhere on how to install VA in another "root suffix" of VS, for testing purposes (i.e. testing without all the other extensions one might install for their work)?
Thanks! |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Oct 05 2023 : 08:44:37 AM
|
I do, but the details vary slightly depending on which version of Visual Studio you are targeting. For ease, the instructions for VS2022 are as follows. First you need to download the VS2022 specific installer for Visual Assist from:
https://downloadfiles.idera.com/WholeTomato/VA_X_Setup2502_0_x64.vsix
Next you will need extra details about the IDE install to create a test profile. To get these details, please open a Windows command prompt window, and inside the window run the command:
"%ProgramFiles(x86)%\Microsoft Visual Studio\Installer\vswhere.exe"
There will be a set of lines for each different version of Visual Studio that you have installed. For the version you want to install into, you want the "productPath", "dispalyName" and "installationVersion" lines, e.g.
productPath: C:\Program Files\Microsoft Visual Studio\2022\Professional\Common7\IDE\devenv.exe
displayName: Visual Studio Professional 2022
installationVersion: 17.4.33213.308
You can then use the information from these three lines to make sure that the following command has the correct command line parameters. The values are:
/appidname: = displayName:
/appidinstallpath: = productPath:
/skuVersion: = installationVersion:
The "/skuName:" value is one of "Community / Pro / Enterprise", note for the Professional version it is "Pro", not the expected "Professional".
The working command, for VS2022, using the values above, is - split into lines to make it easier to read and edit:
"C:\Program Files\Microsoft Visual Studio\2022\Professional\Common7\IDE\VSIXInstaller.exe"
/appidinstallpath:"C:\Program Files\Microsoft Visual Studio\2022\Professional\Common7\IDE\devenv.exe"
/skuName:Pro
/appidname:"Visual Studio Professional 2022"
/skuVersion:17.4.33213.308
/rootSuffix:"VATest" "C:\Users\%USERNAME%\Downloads\VA_X_Setup2502_0_x64.vsix"
The "rootSuffix" is the name of the test profile you want to install to, and this will be created if it does not already exist. The final parameter is the path of the VSIX installer for Visual Assist that you want to install. Once you have the command set up, the only parts you should need to edit are the skuVersion and the path to the VSIX file, can you please close all instances of Visual Studio and run this command.
Running this command installs VA into the test profile, but it does not load the test profile. If you created the test profile by installing VA, when you run the test profile it will be using the default IDE settings, without asking you which settings you want to use.
To now load the test profile you use the command:
"C:\Program Files\Microsoft Visual Studio\2022\Professional\Common7\IDE\devenv.exe" /RootSuffix VATest
To load your normal, default profile just load the IDE normally. To return to this test profile again, pass the /RootSuffix command line switch when loading the IDE. You can run both profiles at the same time, next to each other. In VS2019 and VS2022 the profile name will be shown just under the close button, in the top right hand corner of the main IDE window. If you export your IDE settings from your main profile you can them import them into the test profile. |
zen is the art of being at one with the two'ness |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Oct 11 2023 : 08:57:15 AM
|
I have put in a bug report for this, basically to make sure VA has caught up with the moving keyboard caret before doing an Alt-G, or other context specific command. Only seems to happen under specific conditions, when you are moving around faster than VA can keep up, and not giving VA a chance to catch up:
case=150139 |
zen is the art of being at one with the two'ness |
|
|
|
dcastonguay
Senior Member
Canada
32 Posts |
Posted - Nov 13 2023 : 3:41:03 PM
|
> make sure VA has caught up with the moving keyboard caret before doing an Alt-G
I want to add a bit more information about my "normal" situation, using my day-to-day VS solution. I have disabled VS's Intellisense, as you suggested by email, and the issue seems to occur less frequently and for shorter periods of time, but it does still occur.
I've also noticed that Visual Assist seems to parse the same files over and over again, simply while I'm trying to ctrl-tab between them (which, I suppose, also includes me coming back from a "wrong" Alt+G keypress which sent me to another file). This happens when cycling between 2 .cpp files, between a .cpp and a .h file, or between 2 .h files (and maybe other cases, but those are the ones I just tested). When this happens (i.e. when I see "VA: Parsing <some_file>" in the status bar), if I try to move the caret to a new symbol and press Alt+G, the new caret location isn't taken into account for the operation, and I end up locating the wrong symbol.
Is it expected for Visual Assist to parse files so often/just when navigating through them?
Additional note: I don't know what's the expected speed of parsing, but the .cpp files I was testing with take up to 5 seconds to parse.
Thanks for your help! |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Nov 14 2023 : 05:22:57 AM
|
No, this is not what I would expect.
So long as a file has already been parsed, and it has NOT been edited since, VA should not feel the need to reparse the file. Just swapping between already parsed files should not cause any extra parsing.
If you have:
VA Options -> Performance -> Parse all files when opening a project = OFF
or have:
VA Options -> Projects and Files -> Upon opening a file, parse all other unparsed files in the same directory:
turned On, then it would make sense for VA to be parsing files when you first open a file, but once the files have been parsed, VA is designed to know that it has parsed a file, so it does not need to be parsed again.
Plus the parsing time is really long. How large is the cpp file with the 5 second parsing time? I have a large, but simple test file, to test large files. This is a 30,000 line cpp file, and it parses in a second. Having multiple files that each take several seconds to parse suggests either very complex code or very large files, perhaps both. Or is this time spent parsing all of the included files as well?
I have seen long parsing times with very complex macro code, or very complex template code. But I am talking thousands of lines of solid macros or templates here.
One thought on all of this, can you please look in:
VA Options -> C/C++ Directories
does VA's list of stable include directories overlap with the directories where your solution lives? VA assumes that your stable include directories are separate from your solution, which by definition isn't stable. So if they overlap that can cause some odd effects. VA does have special handling for Unreal Engine solutions, where the engine is part of the solution, but is also stable, but that only matters if you are working with Unreal Engine. |
zen is the art of being at one with the two'ness |
|
|
|
dcastonguay
Senior Member
Canada
32 Posts |
Posted - Nov 14 2023 : 11:50:07 AM
|
quote:
So long as a file has already been parsed, and it has NOT been edited since, VA should not feel the need to reparse the file
The files in question were not modified during the file switching. However, I did have at least one other unrelated .cpp file with unsaved changes while I was testing this. I just tested again, and it seems that having unsaved files might be what triggers the behavior (and I often leave some files unsaved while I'm working). After saving the files, VA seems to parse the other files at least once again when ctrl+tabbing to them, and then stops parsing them.
However, saving the files didn't make my Alt+G issue disappear. While testing this, I could see that it doesn't only occur while I can see VA parsing files in the status bar; I was able to reproduce the issue while there was seemingly no parsing going on. :(
quote:
If you have:
VA Options -> Performance -> Parse all files when opening a project = OFF
I have that option ON, but my solution has been open for a while (for at least 12 hours at this point).
quote:
How large is the cpp file with the 5 second parsing time?
quote:
I have seen long parsing times with very complex macro code, or very complex template code. But I am talking thousands of lines of solid macros or templates here.
The file itself is 3350 lines long, with no templates and no more-complicated-looking-than-usual macros.
quote:
Or is this time spent parsing all of the included files as well?
I don't know how big the totality of the #includes would be (my setup to "preprocess to a file" is kinda broken :( ), but there are probably a ton of #includes, including transitive ones, though.
Would VA report parsing the headers in the status bar in this case, or would it still only say "VA: Parsing <this_file>.cpp" ? Also, we used to have precompiled headers, but I think we don't use them anymore; could this affect Visual Assist somehow? (We still have precomp.h files with tons of includes, but we don't use .pch anymore, I think.)
quote:
One thought on all of this, can you please look in:
VA Options -> C/C++ Directories
does VA's list of stable include directories overlap with the directories where your solution lives?
I'm not sure exactly what you mean by "overlapping" here, but none of the code I would actively change is listed in those folders.
Thanks for you continued help! |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Nov 14 2023 : 1:13:31 PM
|
If VA was parsing included header files then this should be clear, since the name of the header file would be shown in the status bar message. So it sounds like our parser is just really struggling to parse your code files, which seems odd.
First up, do you have:
VA Options -> Performance -> Enable multithreaded parsing
turned On or Off, and what do you have thread priority set to?
For the stable include directories overlapping, if your solution used the directories:
C:\src_tree\branch1C:\src_tree\branch2C:\src_tree\branch2\library1C:\src_tree\branch2\library2
and you then told VA that "library1" and "library2" were stable include directories then you might get odd problems. Normally the external libraries sit in different directories to the solution code, so don't overlap.
You have a good sized solution, but its not scary large.
OK, if you just add a blank line to one of your cpp files, so it is edited, and keep an eye on the status bar, how long does it take VA to reparse the file, without you changing files? At under 4,000 lines I would expect parsing to be near instant. So I am wondering if somehow changing files is a factor in all of this. |
zen is the art of being at one with the two'ness |
|
|
|
dcastonguay
Senior Member
Canada
32 Posts |
Posted - Nov 14 2023 : 1:54:53 PM
|
quote:
First up, do you have:
VA Options -> Performance -> Enable multithreaded parsing
turned On or Off, and what do you have thread priority set to?
It is turned on, capped at 8 threads (on a machine with 6 physical/12 logical cores), w/ priority Normal.
quote:
Normally the external libraries sit in different directories to the solution code, so don't overlap.
I can't find any files under the folders listed in the stable include directories in my solution using VA's Shift+Alt+O; I'm assuming that's a good way to validate overlap?
quote:
OK, if you just add a blank line to one of your cpp files, so it is edited, and keep an eye on the status bar, how long does it take VA to reparse the file, without you changing files?
Actually, I just realized that even when saving the unrelated modified files, I have the same behavior, it's just that it seems VS doesn't always show the VA status in the status bar if there is something else already displayed (e.g. the "Item(s) Saved" feedback).
The files is was testing with, ctrl+tabbing between them:
- File A, 1966 lines: parsing takes ~2.8 seconds
- File B, 3350 lines: parsing takes ~5 seconds. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Nov 15 2023 : 10:34:28 AM
|
These parsing times seem really long for these file sizes.
Can you please try opening the Windows Resource Monitor program, I have a link to open it on the status bar of Task Manager on the Performance tab, in detailed mode.
With Resource Monitor on the CPU tab, you should have a CPU usage graph over time for each CPU core. Can you wait for your machine to settle a little, and then repeat this test please. You should be seeing a serious CPU spike on a single core, since parsing a single code file is a single core task. Multi-threaded parsing takes effect when parsing lots of files.
I just want to make sure that VA is trying to use plenty of CPU time, and that it is CPU bound on parsing your files. If there is no obvious CPU spike then perhaps we are IO bound instead. |
zen is the art of being at one with the two'ness |
|
|
|
dcastonguay
Senior Member
Canada
32 Posts |
Posted - Nov 15 2023 : 12:03:39 PM
|
I had a bit of a hard time getting my machine to settle down (I did see single-threaded peaks when ctrl+tabbing through my files), but I decided to go a little further, and captured an .etl trace of the devenv process.
All processing does seem to occur on the VAX:ConsumerParserThread, and really takes either 3.5 seconds or ~6 seconds, depending on the file (there's probably some overhead from tracing, too).
The bright green indicates the CPU is executing, violet parts are "sleeps" and reddish parts are "synchronizing", e.g. doing I/O, waiting for mutual exclusion, etc. So we can see that the CPU is not waiting for anything in this case.
Since I don't have symbols for the VAX module, I can't really tell what's going on, but if you want, I could share the .etl file somewhere (it's kinda huge, at ~450Mb). |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Nov 16 2023 : 08:37:22 AM
|
If you can upload the etl file somewhere I can download it here and try and have a look. If this is easy you can send me the link at:
[email protected]
including this thread ID or URL in the description, so we can match it up. This avoids sharing the file here.
Even if not, the key point is that this slow parsing really is VA, so somehow our parser really is struggling this badly with your code, which is also effecting Alt-G performance.
Are you seeing this sort of performance in most to all code files, or does it seem limited to just "some" files?
Do you have a couple of files that you would definitely consider to be simple code? I am wondering if you will see the problem there as well.
Guessing here, but if you have a common header file with heavy macros or template code that is slowing our parsing right down then this might explain why this problem happens in "many" files.
Do you tend to use a lot of macros in your code? |
zen is the art of being at one with the two'ness |
|
|
|
dcastonguay
Senior Member
Canada
32 Posts |
Posted - Nov 16 2023 : 10:24:30 AM
|
I've sent the .etl file through Media Shuttle to that email address. If the email hasn't made it, I also have a link I could share privately.
> Are you seeing this sort of performance in most to all code files, or does it seem limited to just "some" files?
I've focused on those two files because there are probably indeed longer than most, but I've seen this issue in many files.
> Do you have a couple of files that you would definitely consider to be simple code? I am wondering if you will see the problem there as well.
Considering the amount of "boilerplate" includes that we have, I'm not sure we have many simple files :) But yes, there are files where the parsing is a lot quicker (some header files I've seen while testing parsed almost instantly).
> if you have a common header file with heavy macros or template code that is slowing our parsing right down then this might explain why this problem happens in "many" files.
> Do you tend to use a lot of macros in your code?
We do have common header files that have what might be considered heavy template/macro usage (but I have a hard time quantifying what "heavy" would be...).
Do we have a way to pinpoint where the parser is struggling? Some sort of option I could enable to get logging or something similar?
Thanks! |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Nov 16 2023 : 11:22:35 AM
|
We can certainly get some VA logs, but it might take a little while before any of our developers dig through them. I can certainly have a look, but the logs are a bit cryptic. If you are happy to send me some logs, this page explains the process:
https://docs.wholetomato.com/default.asp?W305
basically enable logging, get VA to parse a couple of slower files, and then close Visual Studio to stop the log files from growing any larger, and then send me the logs. I will see if I can pin down anything useful.
I have replied to your email, no sign of a download link or attachment, so I am wondering if something got stripped out of the email en-route.
OK, so we have a "file specific", even if it is probably most files, problem. Are you aware of any common macros or boiler plate code that most files with this problem have? I am thinking of something along the lines of:
ADD_STANDARD_INCLUDES;
BUILD_WORKER_CLASS;
just making up names to be honest, but trying to think of something that might often get included. If we are lucky there are a handful of complex macros that we can basically "hide" from VA.
You can create a text file that VA parses before anything else, which is solution specific, but doesn't get added to the solution, so it should be invisible to everything apart form VA.
If this is partly caused by complex macros, we can add empty or very simple versions of the complex macros for VA to use instead, effectively hiding the complex macros, and their impact. The idea is simple, the trick lays in working out what macros you want to hide. |
zen is the art of being at one with the two'ness |
|
|
|
dcastonguay
Senior Member
Canada
32 Posts |
Posted - Nov 17 2023 : 2:01:34 PM
|
> We can certainly get some VA logs
I have sent logs by email.
> Are you aware of any common macros or boiler plate code that most files with this problem have?
> [...] trying to think of something that might often get included.
I have also tested the suggestion of commenting out all #includes in the files, and seeing if it made the issue go away, but the files are still parsed each time I swap between them, and they seem to take the same amount of time to parse.
But yes, we probably do have macros that are used all over the place (macros for logging and assertions are the first ones that come to mind). We also have a code generator than generates macros to hide some of the generated code away in other files more easily. There are probably other many other macro usages.
If we had information about which macro (if any) takes the most time to parse, that would probably help a lot.
Thanks! |
|
|
|
accord
Whole Tomato Software
United Kingdom
3287 Posts |
Posted - Dec 14 2023 : 12:40:35 PM
|
| Which program is the screenshot from? |
Edited by - accord on Dec 14 2023 12:41:42 PM |
|
|
| |
Topic |
|
|
|
GoToImplementation (Alt+G) vs. selection issue
