| Author |
 Topic  |
|
NeedVisualAssistanceX
New Member
4 Posts |
 Posted - Apr 17 2019 : 01:39:26 AM
|
Hey guys. I like Visual Assist X quite a bit and I've been using it for a little under a year now. Unfortunately, the entire time I've been using it, I've been plagued by re-parses that are seemingly invoked by nothing. I'm not sure if this is just something to get used to when using VAX with Unreal Engine 4, or if I'm simply doing something that I shouldn't be doing that triggers a reparse.
My understanding is that as long as I'm working within the same project/solution (which in my case is the generated UE4 Engine project and my game project), and don't literally click the "Rebuild" button on the options dialog, there should be no need to reparse. Yet restarting my computer or seemingly just being away from the project for an extended amount of time seems to trigger a reparse of both my game, and the entire Unreal Engine source, which essentially locks me off of the project for about three hours unless I want to challenge myself with intellisense-less coding.
I've been to this support page several times to try to figure out what I'm doing wrong, but according to the two bullet points, there should be no need for a full reparse. Are there any secret pro-tips for preventing UE4 projects from triggering a reparse of the entire codebase? It's literally my current least favorite thing in the entire world, and I'd love to get it to only parse what's necessary at a given time.
Thanks! |
Edited by - NeedVisualAssistanceX on Apr 17 2019 1:25:40 PM |
|
|
feline
Whole Tomato Software
United Kingdom
19054 Posts |
Posted - Apr 17 2019 : 07:21:31 AM
|
Let's start with the basics. Which IDE and version of VA are you using?
When you see this problem, have you used the Unreal Editor to make changes to your solution? Adding new classes or code files? This might be a factor, but it seems unlikely it is always the cause.
Do you have:
VA Options -> Performance -> Parse all files when opening a project
turned On or Off?
What do you have:
VA Options -> Unreal Engine -> Enable support for Unreal Engine 4
set to?
Assuming you have:
VA Options -> Coloring and Attributes -> Show stable symbols in italics
are any of the Unreal classes being shown in italics inside the editor? This will tell us if VA thinks that the Unreal Engine is being treated as a stable include directory, which should stop it being reparsed by VA. |
zen is the art of being at one with the two'ness |
 |
|
|
NeedVisualAssistanceX
New Member
4 Posts |
Posted - Apr 17 2019 : 10:54:43 PM
|
Thanks for the reply, feline! To answer your questions:
Using Visual Studio 2019.16.0.1 and I believe I'm on Visual Assist X 2324 - or whatever the latest version is.
I definitely see this happen after resetting my PC. I believe it happens after opening the project again after a few hours, but not 100% on that.
VA Options -> Performance -> Parse all files when opening a project: On
VA Options -> Unreal Engine -> Enable support for Unreal Engine 4: On -> When a solution contains a project named UE4
And I have Show stable symbols in italics On, but don't see any italics in my editor. Assuming things like FVector and AActor qualify as "Unreal classes".
To me, "Parse all files when opening a project" seems like the most obvious culprit, but I've avoided disabling it up to this point because I don't want to disable any useful parsing. However, I'll go ahead and experiment with turning it off, since definitely sounds related.
You've got me curious about the "stable include directory" thing though. I can't recall ever seeing UE4 classes being rendered in italics.
|
|
|
|
feline
Whole Tomato Software
United Kingdom
19054 Posts |
Posted - Apr 19 2019 : 06:06:48 AM
|
Both "FVector" and "AActor" are shown in italics for me, testing VS2019 and VA 2324 here.
What about "std::string", is this type shown in italics for you?
Can you please go to:
VA Options -> System Info -> Copy Info
and paste the details (from the clipboard) into your reply. This will give us the basic information about your setup. I would expect to see the unreal directories in your stable include directory list, but I am guessing they won't be there.
How did you install Unreal Engine? Did you use the Epic Game Launcher, or did you download and compile the source code directly from github? Or perhaps some other method?
In Solution Explorer do you have an "Engine" project, holding a "UE4" project? This is the expected structure for a solution using UE4. |
zen is the art of being at one with the two'ness |
|
|
|
NeedVisualAssistanceX
New Member
4 Posts |
Posted - Apr 19 2019 : 11:40:18 PM
|
So I took a shot in the dark, and long story short, it appears that having my Unreal Engine installed to my D: drive instead of the standard C: drive was the cause for the engine files not being picked up as system includes. After moving my installation there, all of the UE4 directories now populate the C/C++ Directories list, and I can now see Unreal classes being rendered in italics. I also reset my PC, and was delighted to see that it's no longer attempting to re-parse the entire engine.
If you'd like, I can still post the results from System Info if that would be helpful to you, but in my case at least, defaulting to the C: drive solved it. Seems obvious in retrospect that it wouldn't automatically scan the Program Files directory of every hard drive by default, but it took a bit for my brain to get there.
Thanks for your help |
|
|
|
feline
Whole Tomato Software
United Kingdom
19054 Posts |
Posted - May 06 2019 : 10:27:40 AM
|
Apologies for the slow reply, UE4 really does not like being tested in virtual machines, which caused some problems with reproducing this problem here. I have reproduced it here now though, and yes, when UE4 is installed to a different drive VA is not automatically adding the UE4 libraries to your stable include directory list:
case=140062 |
zen is the art of being at one with the two'ness |
|
|
|
HateDread
Junior Member
Australia
23 Posts |
Posted - Jun 02 2019 : 07:46:28 AM
|
quote:
Originally posted by feline
Apologies for the slow reply, UE4 really does not like being tested in virtual machines, which caused some problems with reproducing this problem here. I have reproduced it here now though, and yes, when UE4 is installed to a different drive VA is not automatically adding the UE4 libraries to your stable include directory list:
case=140062
Hi feline,
I'm experiencing the above issue on my work PC as well, where the UE4 install is definitely not in the default location (as is the case for most studios, I imagine, where the launcher builds are not the norm). The reparsing is most brutal when restarting VS after it crashes - nothing makes a crash worse than waiting for a full reparse.
Is there a temporary solution to add UE4 in a non-standard location to the stable include list? Is it that the engine needs to be on the C: drive _anywhere_, or specifically in the default location for this to take effect?
UE4 classes are not in italics for me, as one would expect based on this thread's findings.
Thanks!
EDIT: And what about builds we compile ourselves? Are they supported somehow, if they don't change = no reparse? |
Edited by - HateDread on Jun 02 2019 07:47:44 AM |
|
|
|
feline
Whole Tomato Software
United Kingdom
19054 Posts |
Posted - Jun 03 2019 : 11:13:29 AM
|
The bug is down as an important one, and we are hoping for a fix fairly soon, but I don't currently have an estimate for when this will be fixed.
When you say "not the default location", is the UE code on your main drive, normally C drive, or a different drive letter? This bug is specific to having UE code on a different drive letter, not simply a different install location.
So first up I want to see if this should be a factor in the problems you are seeing.
Are you seeing any pattern to the crashes? It is possible that VA is a factor in these crashes, and if so, that's something we would want to look into. For example, do the crashes happen in a very large solution, after it has been open for a while? If so it is possible you are seeing problems with the IDE process (devenv.exe) running out of memory, since it is a 32bit process and can only access 4gig of RAM at absolute maximum.
In VA options, do you have:
VA Options -> Performance -> Parse all files when opening a project
turned On of Off? If this is turned On, does turning this Off make much of a difference? |
zen is the art of being at one with the two'ness |
|
|
|
HateDread
Junior Member
Australia
23 Posts |
Posted - Jun 03 2019 : 10:10:31 PM
|
quote:
Originally posted by feline
The bug is down as an important one, and we are hoping for a fix fairly soon, but I don't currently have an estimate for when this will be fixed.
When you say "not the default location", is the UE code on your main drive, normally C drive, or a different drive letter? This bug is specific to having UE code on a different drive letter, not simply a different install location.
So first up I want to see if this should be a factor in the problems you are seeing.
Are you seeing any pattern to the crashes? It is possible that VA is a factor in these crashes, and if so, that's something we would want to look into. For example, do the crashes happen in a very large solution, after it has been open for a while? If so it is possible you are seeing problems with the IDE process (devenv.exe) running out of memory, since it is a 32bit process and can only access 4gig of RAM at absolute maximum.
In VA options, do you have:
VA Options -> Performance -> Parse all files when opening a project
turned On of Off? If this is turned On, does turning this Off make much of a difference?
It seems like this issue occurs even with UE4 elsewhere on the C: drive.
The complication is (I think) in how you might be determining installed build vs source build.
I'm currently using an installed build we generate ourselves from custom UE4 source, where that installed build is in a non-default location.
Here is a long list of steps, including building a UE4 installed build which will take a while, esp. if you don't have an Incredibuild network across which to distribute the build. A few steps are interconnected so watch out :)
Steps for installed build:
1. Download UE4 source, with e.g. 4.21 branch
2. Run Setup.bat to get dependencies
3. Run GenerateProjectFiles.bat to generation VS solution
4. Open UE4.sln and build just the AutomationTool csproj, then close the sln
5. cd to root of this engine and run something like:
"Engine\Build\BatchFiles\RunUAT.bat" BuildGraph
-target="Make Installed Build Win64"
-script="Path\To\Root\Engine\Build\InstalledEngineBuild.xml"
-clean -set:HostPlatformOnly=true
6. Make/find a UE4 project using the same version of the engine source you pulled from Github, e.g. if you pulled 4.21 branch, use 4.21 in the launcher to make your project (avoids having to build against your newly-generated engine and bloating its size before copying it around in the next step). Can also verify at this step if UE4 symbols are in italics, if desired.
7. Find the generated engine from step 5 at EngineRoot/LocalBuilds/Engine/Windows and copy the folders so they're in a sibling folder to your UE4 project folder, e.g.
Root
MyUE4ProjectFolder
MyUE4Project.uproject
UnrealPackaged
Engine
FeaturePacks
Samples
Templates
8. Change your UE4 project from step 6 to use this packaged engine version by opening the project's .uproject and set it to use a relative engine path, e.g.
"EngineAssociation": "../UnrealPackaged",
9. (re)generate a solution for your UE4 project by right-clicking the .uproject file and selecting "Generate Visual Studio project files"
10. Open the solution and observe lack of italics on UE4 classes.
---------------------------------------
Re. crashes - I will keep an eye out. I believe, from memory, that they're mostly around intellisense/VAX operations now that you mention it. The other common situation is for VS to lock into "Microsoft Visual Studio is busy" notification and never escape. Could you see that being VAX-related as well?
Will look into "Parse all files when opening a project". How does VAX build up its understanding of something like UE4 source builds without this option enabled?
[Edited by sean to fix text wrapping/flow on the page -- I broke out the command arguments to separate lines] |
Edited by - sean on Sep 16 2019 7:39:46 PM |
|
|
|
feline
Whole Tomato Software
United Kingdom
19054 Posts |
Posted - Jun 04 2019 : 12:19:08 PM
|
I have a test case for a source build of Unreal Engine, but perhaps it was put together differently. I recall having problems trying to get it to work. I am following these steps now to start creating a new, locally built unreal engine. This will probably take a little while, but it clearly needs doing if there is a separate problem at work here.
Once VA has parsed the Unreal Engine at least once it will be remembered, until you rebuild the VA symbol database. Beyond this, when you open a code file VA will parse the included files, so assuming VA starts with no knowledge of Unreal Engine, it will slowly build up a knowledge of the engine as you open up and edit code files.
VA should also only parse files that have been changed since the last time they were parsed. Part of the problem with Unreal Engine is simply the sheer size, the large number of files to check. Still, VA should be treating unreal as a stable library, which is what I want to test here. |
zen is the art of being at one with the two'ness |
|
|
|
feline
Whole Tomato Software
United Kingdom
19054 Posts |
Posted - Jun 05 2019 : 1:37:52 PM
|
I am having problems with this, but I don't know why. Perhaps I am just missing something obvious?
I have run the first 5 steps, apparently without any problems. For step 6 I have moved to a different machine where I have the previously installed the Epic Game launcher, and used that to download and install Unreal Engine, and found a simple test game project created there.
Step 7 though, I don't have any sign of this generated engine directory "EngineRoot/LocalBuilds/Engine/Windows". Doing a search across the entire hard drive of both machines, one with the github source code downloaded, and one with the epic engine installed, for something called "LocalBuilds" is not finding anything.
It is possible that this is because I set Github to use the 4.18 branch of Unreal Engine, but I did this since this is the last version of the Unreal Editor that will load in a VMware Workstation virtual machine, which is where I am trying to perform these tests, to avoid making a mess of the machine where I already have the Epic launcher installed, and that installed Unreal editor.
If I don't actually need to run the unreal editor GUI then I can try the same tests with the current version of Unreal Engine.
Which begs the question, when you are doing this, on the machine where you are seeing the problem with VA, have you ever actually run / used the Unreal Editor GUI? I am wondering if this could somehow be a factor in all of this. |
zen is the art of being at one with the two'ness |
|
|
|
HateDread
Junior Member
Australia
23 Posts |
Posted - Jun 05 2019 : 6:40:52 PM
|
quote:
Originally posted by feline
I am having problems with this, but I don't know why. Perhaps I am just missing something obvious?
I have run the first 5 steps, apparently without any problems. For step 6 I have moved to a different machine where I have the previously installed the Epic Game launcher, and used that to download and install Unreal Engine, and found a simple test game project created there.
Step 7 though, I don't have any sign of this generated engine directory "EngineRoot/LocalBuilds/Engine/Windows". Doing a search across the entire hard drive of both machines, one with the github source code downloaded, and one with the epic engine installed, for something called "LocalBuilds" is not finding anything.
It is possible that this is because I set Github to use the 4.18 branch of Unreal Engine, but I did this since this is the last version of the Unreal Editor that will load in a VMware Workstation virtual machine, which is where I am trying to perform these tests, to avoid making a mess of the machine where I already have the Epic launcher installed, and that installed Unreal editor.
If I don't actually need to run the unreal editor GUI then I can try the same tests with the current version of Unreal Engine.
Which begs the question, when you are doing this, on the machine where you are seeing the problem with VA, have you ever actually run / used the Unreal Editor GUI? I am wondering if this could somehow be a factor in all of this.
It's possible that the BuildGraph system was a bit different in 4.18, but I'm surprised that if that's the case, step 5 still worked. You should see at the end of step 5 some output like (from memory): "Successfully copied to x/y/z", which would be your LocalBuilds. To be clear, when I said "EngineRoot" I literally meant your source build's root directory. So you should see LocalBuilds next to 'Engine' etc. Could be worth trying 4.21 for step 5, and only messing up your install if you get this folder from step 5.
I have definitely run the launcher GUI at some point, for sure. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19054 Posts |
Posted - Jun 15 2019 : 09:49:25 AM
|
| Wall, head, bang. Every time I try and get this to build, something goes wrong. Eventually I will run out of problems that need to be fixed, and things that need to be done to make this build, and I can actually test this. |
zen is the art of being at one with the two'ness |
|
|
|
HateDread
Junior Member
Australia
23 Posts |
Posted - Aug 22 2019 : 09:22:19 AM
|
quote:
Originally posted by feline
Apologies for the slow reply, UE4 really does not like being tested in virtual machines, which caused some problems with reproducing this problem here. I have reproduced it here now though, and yes, when UE4 is installed to a different drive VA is not automatically adding the UE4 libraries to your stable include directory list:
case=140062
Hi,
Was there any progress on this case? For example, if I have a stable copy of the engine in a non-standard location, can I avoid the constant reparsing on solution open? I know that the engine won't change.
Disabled parsing on load will make VAX perform much worse, however - I'd like the best of both worlds! |
|
|
|
HateDread
Junior Member
Australia
23 Posts |
Posted - Aug 24 2019 : 12:27:02 AM
|
quote:
Originally posted by HateDread
quote:
Originally posted by feline
Apologies for the slow reply, UE4 really does not like being tested in virtual machines, which caused some problems with reproducing this problem here. I have reproduced it here now though, and yes, when UE4 is installed to a different drive VA is not automatically adding the UE4 libraries to your stable include directory list:
case=140062
Hi,
Was there any progress on this case? For example, if I have a stable copy of the engine in a non-standard location, can I avoid the constant reparsing on solution open? I know that the engine won't change.
Disabled parsing on load will make VAX perform much worse, however - I'd like the best of both worlds!
Just thinking about this - as a quick fix, can I add my non-C drive UE4 install to the system includes in VAX permanently? I think if I add them via the VAssistX drop-down menu, they'll only persist until I regenerate the solution, right? That is pretty common in the UE4 workflow, so I'd like to avoid reparsing when doing that. Would be good to permanently add this UE4 install's source directories e.g. via the Windows registry, or have some other GUI-based way to do this. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19054 Posts |
Posted - Aug 24 2019 : 07:41:39 AM
|
| Are you able to change the name of the tree that the unreal source code is copied into, "UnrealPackaged" in this case? I have a theory for how to fix this, and am currently running some tests on it now, that I have finally worked out all of the pre-requisites to get Unreal Engine source to compile here. |
zen is the art of being at one with the two'ness |
|
|
|
HateDread
Junior Member
Australia
23 Posts |
Posted - Aug 24 2019 : 08:31:05 AM
|
quote:
Originally posted by feline
Are you able to change the name of the tree that the unreal source code is copied into, "UnrealPackaged" in this case? I have a theory for how to fix this, and am currently running some tests on it now, that I have finally worked out all of the pre-requisites to get Unreal Engine source to compile here.
Oh, I wasn't clear - this time, I'm literally using a version of the engine downloaded using the Epic Games Launcher, just now at this following, non-default path:
quote:
D:\Programming\Tools\Unreal Engine\UE_4.22
I have added D:\Programming\Tools\Unreal Engine\UE_4.22\Source to the system includes in VAX manually.
Interestingly, once I removed this from my system includes in VAX, the UE4 types remain in italics, yet when I jump to them, it's the wrong UE4 version, i.e. a UE4 install in the default location which has been picked up and added to the system includes by VAX automatically. |
Edited by - HateDread on Aug 24 2019 08:34:18 AM |
|
|
|
feline
Whole Tomato Software
United Kingdom
19054 Posts |
Posted - Aug 24 2019 : 10:43:51 AM
|
I now have a test case set up for your original situation, and I am seeing the problem with no UE symbols being shown in italics. It looks like in this situation VA is not detecting that this is an Unreal Engine using solution, although it clearly is.
I am currently looking into this, to try and see if I can find a solution to fix this.
There is a known problem that VA does not automatically pick up the Unreal Engine stable include directories when Unreal it's self is installed to a different drive letter, which it sounds like you are now encountering:
case=140062 |
zen is the art of being at one with the two'ness |
|
|
|
HateDread
Junior Member
Australia
23 Posts |
Posted - Aug 24 2019 : 10:52:35 AM
|
quote:
Originally posted by feline
I now have a test case set up for your original situation, and I am seeing the problem with no UE symbols being shown in italics. It looks like in this situation VA is not detecting that this is an Unreal Engine using solution, although it clearly is.
I am currently looking into this, to try and see if I can find a solution to fix this.
There is a known problem that VA does not automatically pick up the Unreal Engine stable include directories when Unreal it's self is installed to a different drive letter, which it sounds like you are now encountering:
case=140062
Thanks for the reply - is there any workaround for this known issue? Should I manually add every source directory from the non-C drive UE4 install? E.g. Engine/Source, Engine/Source/Runtime/Launch, Engine/Source/Runtime, Engine/Source/Runtime/Core/Public, etc? It's a lot of manual work :)
EDIT: Can I batch-add a bunch of directories? I could copy the ones automatically-added for my other install and change the paths to match the non-C drive install and reinsert them. |
Edited by - HateDread on Aug 24 2019 10:54:12 AM |
|
|
|
feline
Whole Tomato Software
United Kingdom
19054 Posts |
Posted - Aug 27 2019 : 1:19:03 PM
|
In theory adding the directories should fix this problem, in both situations, but so far, in my tests, I have been unable to get this to work. I am currently trying to figure out why.
However, I am seeing one important seeming difference with your system. Even when none of the Unreal Engine symbols are being shown in italics by VA, and I have turned On:
VA Options -> Performance -> Parse all files when opening a project
VA is not re-parsing the Unreal Engine code when I close and reload the IDE.
This is what I expect to see, since in these tests the version, and the files making up the engine, have not changed. VA does check to see if the files have changed before reparsing them, so if the version of the engine has not changed, then VA should not be reparsing all of this code.
Are you actually seeing signs that VA is reparsing the entire engine all of the time? |
zen is the art of being at one with the two'ness |
|
|
|
feline
Whole Tomato Software
United Kingdom
19054 Posts |
Posted - Aug 27 2019 : 2:34:49 PM
|
In the solution where VA is taking you to the wrong version of the Unreal Engine, have you done a VA symbol database rebuild since changing solutions? The test system I produced from your earlier instructions has two copies of Unreal Engine installed, in two different path's, but VA is always taking me directly to the correct version of Unreal, based on the paths of the files I am jumping to.
Given that Unreal should be part of the solution in all of these cases, I am not sure why VA would be jumping to the wrong version, unless your symbol database is out of date. |
zen is the art of being at one with the two'ness |
|
|
|
sean
Whole Tomato Software
USA
2817 Posts |
Posted - Sep 16 2019 : 7:33:42 PM
|
@HateDread The issue of symbols not being rendered as italic (case=140062) is, so far as I can tell, unrelated to the issue of constant parsing of engine source. We would really like to get that constant parsing problem addressed, but first we need to understand why it is happening.
Do you have VA 2341.2 installed?
Does the problem occur after a simple immediate reload of the solution?
Or is the problem dependent upon some sort of state change or command execution outside of VS before loading the solution?
If you have a way to repro, please enable VA logging before you load the solution (see details at https://support.wholetomato.com/default.asp?W305).
It would be helpful if you could capture separate logs for a couple of solution loads, by:
- exiting VS
- saving the previously generated va.log
- resetting whatever state is necessary to repro
- then enabling logging again
- loading the solution again
Then zip up the saved va.log files and email to support at wholetomato.com |
Edited by - sean on Sep 16 2019 7:42:11 PM |
|
|
|
NeedVisualAssistanceX
New Member
4 Posts |
Posted - Oct 02 2019 : 02:54:23 AM
|
| Hello again! Looks like I wasn't totally alone with my issue, so that's always good to see. Reading the replies, the answer would appear to be "not quite", but just wondering if there's any set of steps that I could follow to make sure Visual Assist X recognizes the UE4 source from an arbitrary directory that isn't on the C drive? I've left it on the C: drive for the past few months, but it'd be rather swell if I could move it to another drive/location of my choosing. UE4 is not a small set of software! |
|
|
|
ChrisG
Whole Tomato Software
USA
299 Posts |
Posted - Oct 02 2019 : 03:07:43 AM
|
You should be able to place the UE4 source directory whoever you please. UE4 symbols will may not appear in italics. That's not to say there aren't issues with unnecessary parsing potentially popping up in some cases. Unfortunately, we don't have any reproduction for those issues as of yet.
If you can reproduce unnecessary parsing, please contact [email protected], and collect logs as described by Sean above. That would be a tremendous help.
Additionally, it's a good idea to make sure Visual Studio isn't just crashing and also that Visual Studio is fully shutting down after you close it. |
|
|
|
OmegaNemesis28
Junior Member
USA
16 Posts |
Posted - Apr 08 2022 : 2:16:36 PM
|
Just reviving this thread since it seems like it's a problem even with UE5 source. I catch my VSX in VS2019 doing this sporadically when I open the solution up, reparsing the entire contents of my Engine source folder when it's definitely done it before. This means I cannot use VSX for up to an hour after opening my solution.
It does not reliably happen on load, something seems to trigger it and I can never collect logs on it when it happens because it's already happening. I'll try to remember to always enable logging every time I reboot VSX since it turns off automatically which it difficult to track. If I do collect logs, I'll post them here and email as well.
VA_X.dll file version 10.9.2440.0 built 2021.11.17
DevEnv.exe version 16.11.32228.343 Professional
msenv.dll version 16.0.32228.297
Comctl32.dll version 6.10.19041.1110
Windows 10 10.0 2009 Build 19044.1586
64 processors (x86-64, WOW64)
Language info: 1252, 0x409 |
|
|
|
feline
Whole Tomato Software
United Kingdom
19054 Posts |
Posted - Apr 11 2022 : 07:49:57 AM
|
Clearly this shouldn't be happening. Also, it sounds like VA is taking longer than it should to parse Unreal Engine, unless you have a slower machine.
As a first check, can you please open VA's Options dialog and go to the C/C++ Directories page. Does VA list all of the directories inside Unreal Engine 5 in the list of stable include directories?
If not, where, on which drive and in which directory do you have Unreal Engine installed? There is a known limitation in VA, that it won�t correctly pick up the Unreal Engine directory tree if it installed outside of "C:\Program Files\", which you might be running into, and I do have a work around for this, which might help a bit.
You mention logs, can you please look for the file
C:\Users\%USERNAME%\AppData\Local\Microsoft\VisualStudio\<IDE version>\Extensions\<random hash>\Data\Startup.log
where the IDE version directory will be "16.0.xxx" where the last part is a hash. You should only have one such directory though, making it easy to find. Another user who is reporting regular reparsing of Unreal Engine does have this file, and it is logging messages about VA's symbol database being corrupt, so its possible you will have the same thing.
If VA detects that its symbol database is corrupt then it will automatically rebuilt it, which seems to be why the other user is seeing VA doing a lot of reparsing of Unreal Engine. |
zen is the art of being at one with the two'ness |
|
|
|
OmegaNemesis28
Junior Member
USA
16 Posts |
Posted - Apr 21 2022 : 8:52:13 PM
|
The corrupt database is correct, I'm seeing a lot of it.
GetSymDefStrs idx c:\users\SomeUser\appdata\local\microsoft\visualstudio\16.0_ccada75a\extensions\xlb0fwhn.es0\Data\vs16_1\cpp\Db10Ds.db is corrupt, fid=0x56772f12, sp=0x2, rel=0xcba0, act=0x204db5 tid=87492 uiTid=130840:330 4/21/2022 20:25:55 0x155c4
Where Db<>s.db is a bunch of various files saying similar. So something is corrupting them. I have another thread open about the VSX slow parsing but I havent had time to go through those steps yet. But if I can fix the corrupting leading to the reparsing as the root of the issue then it wouldn't be so bad.
To answer the first question of the C++ directories if that matters, they are pointing to `C:\Root\Engine\` where `Root` is a symlink to my D drive, both SSDs.
|
|
|
|
feline
Whole Tomato Software
United Kingdom
19054 Posts |
Posted - Apr 22 2022 : 06:55:33 AM
|
Apologies for this. The corrupt database will explain the regular reparsing, but it doesn't give us any clues as to the source of the corruption. Are you seeing the IDE crash at all? I assume not, since you probably would have mentioned it, but best to ask and check.
I am asking our developers if they have any way to help us track the cause of the corruption, since it should not be turning up like this:
case=148072
The over slow parsing problem I have run into, so far is only showing up when VA is told that Unreal Engine is on a different drive letter, so I will double check that this path on C drive doesn't seem to trigger it as well.
In VA Options, what do you have:
VA Options -> Unreal Engine -> Index plugins (requires restart) = None / Referenced / All
set to? Setting this to None or Referenced should speed parsing up a fair bit, by cutting down the amount of code that VA needs to parse.
Do you have IDE intellisense Enabled or Disabled? This is normally disabled via:
IDE tools menu -> Options -> Text Editor -> C/C++ -> Advanced -> Disable Database = True
it might be worth trying to disable this, if it isn't already disabled. I am thinking about the total amount of memory the IDE uses, since VS2019 is a 32bit process, and is limited to 3 GB of RAM, and Unreal Engine makes for a very large solution. |
zen is the art of being at one with the two'ness |
|
|
|
feline
Whole Tomato Software
United Kingdom
19054 Posts |
Posted - Apr 25 2022 : 07:53:16 AM
|
No obvious performance problems here, placing UE 5 under "C:\Root\Engine\"
Getting VA to rebuild its entire symbol database, using the UE setting:
VA Options -> Unreal Engine -> Index plugins (requires restart) = Referenced
took about 20 minutes. This is accessing UE via a junction point. So you should not be running into the really slow VA parsing bug I have encountered with this UE install location. |
zen is the art of being at one with the two'ness |
|
|
|
OmegaNemesis28
Junior Member
USA
16 Posts |
Posted - May 02 2022 : 4:16:12 PM
|
quote:
Originally posted by feline
Apologies for this. The corrupt database will explain the regular reparsing, but it doesn't give us any clues as to the source of the corruption. Are you seeing the IDE crash at all? I assume not, since you probably would have mentioned it, but best to ask and check.
I am asking our developers if they have any way to help us track the cause of the corruption, since it should not be turning up like this:
case=148072
The over slow parsing problem I have run into, so far is only showing up when VA is told that Unreal Engine is on a different drive letter, so I will double check that this path on C drive doesn't seem to trigger it as well.
In VA Options, what do you have:
VA Options -> Unreal Engine -> Index plugins (requires restart) = None / Referenced / All
set to? Setting this to None or Referenced should speed parsing up a fair bit, by cutting down the amount of code that VA needs to parse.
Do you have IDE intellisense Enabled or Disabled? This is normally disabled via:
IDE tools menu -> Options -> Text Editor -> C/C++ -> Advanced -> Disable Database = True
it might be worth trying to disable this, if it isn't already disabled. I am thinking about the total amount of memory the IDE uses, since VS2019 is a 32bit process, and is limited to 3 GB of RAM, and Unreal Engine makes for a very large solution.
Plugins is currently none (I'd like to have it on but can't risk the downtime)
Disable Database is false. I can try to set it to true temporarily but that will remove ClangFormat support which I rely on.
VS itself usually doesn't crash on me. UE can crash often though. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19054 Posts |
Posted - May 04 2022 : 05:44:51 AM
|
I didn't expect the IDE's clang formatting to depend on the intellisense database, but indeed it does. That is a bit unhelpful, I assume that clang format has been merged into the IDE, rather than existing as a stand alone tool.
If you want to try disabling IDE intellisense, I have found this extension:
https://marketplace.visualstudio.com/items?itemName=LLVMExtensions.ClangFormat&ssr=false#overview
based on a couple of quick tests, it is picking up and using my ".clang-format" file without having to do anything, but it is using a different keyboard shortcut to trigger formatting by default than the IDE.
For plugin parsing, setting:
VA Options -> Projects and Files -> Upon opening a file, parse all other unparsed files in the same directory:
* if Solution is not empty
Since the plugins are split into directories, this will let VA parse one directory at a time, if the files have not already been parsed. Not ideal, but it should help.
Another thought, although it is rather manual, is to make a backup copy of VA's symbol database directory after VA has finished parsing everything, but before you have done much, so open the IDE, let VA's parsing finish, I am thinking over night here, then close the IDE and back up the directory. From the log file line above we know it is currently stored in:
c:\users\SomeUser\appdata\local\microsoft\visualstudio\16.0_ccada75a\extensions\xlb0fwhn.es0\Data\vs16_1
you could use a script to copy the database copy back across, and then load the IDE, so it gets done in "one" action.
A bit ugly, and I would love to get to the bottom of this corruption problem so you don't have to consider this, but it is a thought. |
zen is the art of being at one with the two'ness |
|
|
|
Topic |
|
|
|
How to avoid unnecessary reparsing [UE4]
