Intellisense always updating

drakgoku commented 1 year ago

Environment

OS and version: W11 Pro (10.0, compilation 22000)
VS Code: 1.78 (The version doesn't matter. It happens with everyone)
C/C++ extension: C/C++ Extension Pack v1.3.0 Microsoft
GDB / LLDB version:

Bug Summary and Steps to Reproduce

Bug Summary: Every time I save, the intellisense is activated again, indexing the entire project, making it impossible to perform its function, which is to display the methods, properties... as well as the information.

[ - Steps to reproduce the problem - ]

1 - I write the code 2 - When I save anything (right here the intellisense re-indexes the whole project)

Every time I save we get: 1 - Indexing of the entire project.

What it does is: 1 - When I save it sends a notify 2 - That notify indicates that it was saved or there was a change 3 - Index the entire project again.

Debugger Configurations

Is too long. I only put a part.

    "version": "2.0.0",
    "tasks": [
        {
            "label": "MyProject_test Win64 Debug Build",
            "group": "build",
            "command": "Engine\\Build\\BatchFiles\\Build.bat",
            "args": [
                "MyProject_test",
                "Win64",
                "Debug",
                "E:\\IDE\\Epic Games\\Projects UE\\MyProject_test\\MyProject_test.uproject",
                "-waitmutex"
            ],
            "problemMatcher": "$msCompile",
            "type": "shell",
            "options": {
                "cwd": "E:\\IDE\\UE_5.1"
            }
        },
        {

Debugger Logs

Other Extensions

C/C++ Extension Pack (Microsoft)

CMake Tools (Microsoft)
CMake (Microsoft)

Additional Information

[Settings -> Intellisense]

C_Cpp: intelli Sense engine Controls the Intellisense provider in

"Tag Parser" (No) does not update compile-time errors
Default (Yes) analyzes errors at compile time.

I can't put it in "Tag parser" otherwise it's like the errors don't work.

sean-mcmanus commented 1 year ago

What makes you believe it's indexing the entire project? I see no indication of that in the logging or screenshots you've provided. I just see "IntelliSense: Updating", which means the cpptool-srv process is updating the current TU -- there is no indexing of the project (the 2nd status row says "Parsing Complete"). How long does the IntelliSense update take to complete?

drakgoku commented 1 year ago

With a stopwatch: ~17.97 sec when the error detector detects if it is correct or not. ~16.34 sec when intellisense works.

The strange thing is that it only happens in C++ .h files (headers) and not in .cpp files (body)

.cpp ( 2 ~ 3 sec)

.h (approximately 20 sec)

I have activated: C/C++::Toggle Intellisense Engine Fallback on include Errors C/C++::Enable Error Squiggles and no, they do not overlap because I have tested them independently.

and there are times when I have to close because one of these things happens: 1 - Errors are not detected 2 - Shows you a meaningless error

In VS you don't have these problems.

sean-mcmanus commented 1 year ago

Can you try setting C_Cpp.intelliSenseCacheSize to 0? In VS, they have some additional optimizations, such as https://github.com/microsoft/vscode-cpptools/issues/3628 .

drakgoku commented 1 year ago

Now the .cpp takes 15 seconds to detect it or a simple modification.

I'm sending you the example project "has nothing" so you can see it and try it. So you will try one by one. https://drive.google.com/file/d/15xdeuXEKsRTTk_Unwc4zMg33EsWpGlCj/view?usp=share_link

Remember this: They have to get the same errors as VS for this you have to activate: C/C++::Toggle Intellisense Engine Fallback on include Errors C/C++::Enable Error Squiggles They also have to be in real time. C_Cpp: intelli Sense engine Controls the Intellisense provider in "Tag Parser" (No) does not update compile-time errors Default (Yes) analyzes errors at compile time.

Note: .CPP and .h files are in the source/private or public directory. You also need other .net files that come with Visual studio for Unreal Engine... I don't know if you will be able to run it.

Can you find a solution today?, I don't want to go to VS.

drakgoku commented 1 year ago

Visual studio disgusts me that you can't even create folders that you have to swap the solution view to create a folder on disk and then it doesn't appear since it has its own virtual folder path....

I'm fed up with IDEs from well-known brands that don't even do the job for you.

Can you please fix VSC? Or I'm going to Rider, I'm not going to think about it for more than 30 minutes.

sean-mcmanus commented 1 year ago

We haven't had a chance to investigate the issue yet. We haven't received other reports of edits to header files taking a lot longer than source files yet and it doesn't repro in general.

drakgoku commented 1 year ago

Sometimes it takes 2 or 3 seconds in .cpp I don't understand why. Here a video about the problem: https://i.imgur.com/qTjLCKS.mp4

I also provided: The cache and memory at 16384 MB, it seems that something improved (2 or 3 seconds) but nothing more.

I think you have not received other reports because: 1 - Companies do not bother to waste time. "They don't have the same free time as all of you" 2 - They look for other ways instead of wasting time. 3 - People prefer to post on other sites: https://www.reddit.com/r/vscode/comments/l5hz4i/c_intellisense_and_parsing_super_slow/ https://stackoverflow.com/questions/65045405/visual-studio-code-c-intellisense-performance-problems https://community.gamedev.tv/t/visual-studio-code-intellisense-and-parsing-is-really-slow-fix/179184 https://github.com/microsoft/vscode-cpptools/issues/6763 and many others. 4 - You close the post or you don't find problems or you simply don't investigate them.

@sean-mcmanus do you think people have time to waste?

If I'm not mistaken you have a salary from Microsoft in Redmond, WA. Please don't take things lightly or say: 1 - "We found no problems" 2 - "We haven't looked at it" 3 - "We cannot reproduce the problem" 4 - "I try to make excuses since I don't know how to solve the problem:)" 5 - "We haven't received other reports of edits to header files taking a lot longer than source files yet and it doesn't repro in general"

When companies see many problems, they prefer to pay. Either Rider or another IDE.

But you will think: @sean-mcmanus: "I'm doing so well, we don't have any mistakes. We're cracks" Users: Installing other IDEs or JetBrains products Businesses: Installing other IDEs or JetBrains products @sean-mcmanus: "Such a calm day don't you think mike?" Mike: "It's just that we are beasts" Me: "... why can't I get violent, because if not..."

Note: Yes, I have VS and Rider installed and "working". No, I'm not a big fan of JetBrains. They think they are the best to have an IDE based on money, but at least they solve it I'm going to have to think that they're the best, too... If in the end everyone says that something is beautiful, I'm going to have to say it too. And that is not not having personality, that is being able to go with the flow and do it well. ㅤ ㅤ ㅤ Note: I should complain about those 2 or 3 even 4 seconds that Intellisense sometimes takes in .cpp As well as the autocompletion of the .cpp in the methods, constructors or others is not entirely correct since it does not show you the options that you are entering or the ones that remain as Intellij does. Surely you have not even seen this functionality... that's how it goes. Even eclipse has it.

But how am I going to complain about what is really essential if the basics don't work?

bobbrow commented 1 year ago

With a stopwatch: ~17.97 sec when the error detector detects if it is correct or not. ~16.34 sec when intellisense works.

The strange thing is that it only happens in C++ .h files (headers) and not in .cpp files (body)

.cpp ( 2 ~ 3 sec)

.h (approximately 20 sec)

I have activated: C/C++::Toggle Intellisense Engine Fallback on include Errors C/C++::Enable Error Squiggles and no, they do not overlap because I have tested them independently.

and there are times when I have to close because one of these things happens: 1 - Errors are not detected 2 - Shows you a meaningless error

In VS you don't have these problems.

VS Code doesn't have the tailored support for Unreal Engine projects that VS does and the C++ team strongly recommends using VS for Unreal Engine projects because of all the extra attention they're getting in that IDE.

We're sorry that you are upset and frustrated with the VS Code experience for Unreal Engine projects, but the resources to support Unreal Engine are currently being spent on Visual Studio. Some of that work trickles back into VS Code because we do share a lot of code with the VS team, but not all of it.

The reason for the time difference between source and headers is that IntelliSense tries to cache the parsing of headers to reduce the amount of time necessary to update IntelliSense in the source files. When you edit a header file, that cache is currently not salvageable. Unreal Engine projects have a huge number of includes and there were some recent changes to the layout in UE 5.1 that increased the included header count even more. We have been working on fixing performance issues that started with UE 5.1 and have gotten the header parse time down to about 8-9 seconds from 16-17 so far (tested in Visual Studio). Those changes will be available in 17.7 Preview 1 which is supposed to drop this week, but have not made their way into a release of VS Code yet nor have they been tested in VS Code to see if the improvements will match. @sean-mcmanus was incorrect about there not being any reports about this for Unreal Engine. We see more of them on the VS side though and he focuses on VS Code.

drakgoku commented 1 year ago

Thank you very much for the clarification. I read something like this here: https://devblogs.microsoft.com/cppblog/18x-faster-intellisense-for-unreal-engine-projects-in-visual-studio-2022/ https://stackoverflow.com/questions/65045405/visual-studio-code-c-intellisense-performance-problems https://forums.unrealengine.com/t/visual-studio-intellisense-slow-vs2019-ue4-25-1/468154 (Old) https://github.com/microsoft/vscode-cpptools/issues/5490

Then I'll see if I use VS or Rider. The problem with VS is that it is very annoying with the folders and I can't see all the config files In rider, on the contrary, I can visualize everything but it overflows in Ram

sean-mcmanus commented 1 year ago

@bobbrow I mean I haven't seen reports where it's fast in the .cpp and that didn't seem like https://github.com/microsoft/vscode-cpptools/issues/3628 . The user reported that there wasn't a significant difference in timing when intelliSenseCacheSize was set to 0, so that didn't explain the source vs. header timing difference. If there are lots of headers to parse that aren't cached, then that would mean edits to the source file would be slow as well. I was thinking maybe the header was being associated with a different, larger TU than the source file (that could be determined via running the C/C++: Log Diagnostics command).

So this is a duplicate of https://github.com/microsoft/vscode-cpptools/issues/3628 ?

sean-mcmanus commented 1 year ago

I'm guessing the 2-3 seconds is when editing a function/method definition (which only has to reparse the function definition, except when a reparse is triggered) and the 15+ seconds is when updating something in the global scope which is more expensive, and it's not related to it being in a source file or header.

bobbrow commented 1 year ago

I'm guessing the 2-3 seconds is when editing a function/method definition (which only has to reparse the function definition, except when a reparse is triggered) and the 15+ seconds is when updating something in the global scope which is more expensive, and it's not related to it being in a source file or header.

Yes, this is correct. It tends to happen more frequently in header files so I presumed keeping the explanation simple was acceptable. It is possible to get 15+ seconds in the source files as well.

Regarding #3628, explicit PCH may help in some cases, but I don't believe that issue solves this one. I think the primary pain point is the frequent 15+ second updates. We should be getting some speed up from taking the next merge of IntelliSense code from VS, but the recommendation to use VS for Unreal Engine projects is still valid. We're still working on ways to make this even faster, but some of the new ideas are pretty costly to implement even to get to a point where we can test them.

drakgoku commented 1 year ago

@bobbrow I'm back to VS again and I don't have many complaints except for the format that I have to customize a .clang-format (since there are many options in VS that it doesn't incorporate like the number of columns of text/code size...), folder creation, hotkeys and other unimportant...

VSC and VS, although different, are part of Microsoft. Some possible ideas could be: VSC 'could' deploy module/source code with its libraries as well as intellisense, from VS to VSC with the same performance for parsing Unreal Engine projects

Otherwise, alternatives to intellisense could be incorporated: Without going out of cost (usually a smart code detector is worth money), you could use intellicode (Microsoft's own) as long as its performance was much higher than intellisense.

I don't know how difficult the implementation of the first idea would be. But the second one could work much faster and its implementation would be practically not so complex.

drakgoku commented 1 year ago

I'm really happy to be back in VS, because of some (a lot) of minor (very major) bugs. It is not necessary that you implement any idea, it is better that it stays in "idea".

VS VSC https://docs.unrealengine.com/5.2/en-US/unreal-engine-uproperty-specifiers/

https://forums.unrealengine.com/t/things-about-generated-body/605696

- 1 - VS gives errors everywhere that are not errors
- https://forums.unrealengine.com/t/things-about-generated-body/605696
- 2 - It does not have good usability
- 3 - Intellisense shit. Did I say shit? yes, we confirmed i said "shit". I think the word is "Poop" defines it best.
- 4 - Folders... No VS implements his crazy idea of having a virtual folder system (having to create the folders by hand, unfortunate)
- 5 - Copy paste of files "error" you have to add them with the ADD
- 6 - The format of the code? too limited making you have to take external files to modify line by line
- 7 - Keyboard shortcuts, an action such as commenting or uncommenting cannot be assigned with the same two keys.
- ... (be careful that it has the toggle...) and there are other important ones that I am not going to mention
- 
- This would become very mean if it continued.
- Good job, nice house you bought with Microsoft money? Do you have a nice car? A good computer? do you have...?, so be thankful that the stars aligned and keep your place here, otherwise, we might run into each other when I go to buy bread at the bakery.
Me: "Please a loaf of bread."
Former Microsoft employee: "Gladly"
Me: "How nice this man"

I have no words. Now I really know what to do.

I think there are many "good" programmers but none in sight. What a pity that the good ones are sometimes not where they belong.

By the way, if any of the Microsoft employees think this is "disrespectful", "or are offended by language that you use in your own privacy and that in public you pass yourself off as a flanders", let me tell you a thing or two.

1 - You have a salary from Microsoft 2 - You don't have pressure because there are too many unresolved errors. 3 - You waste our time and money 4 - As your bosses (the users who buy and use Microsoft stuff), you have no right to be offended by telling the truth. Since the food you put in your mouth comes out of our pockets. So get to work.

Anyone who is not part of Microsoft and sees this as disrespectful, "I care as much as the weather in Japan."

Rider at least tells me everything that is not correct and rightly so. As if I want to consume 64GB of Ram: I would even buy 1TB of ram.

bobbrow commented 1 year ago

Thank you for your feedback. I'm sorry that you feel frustrated by the shortcomings in the Microsoft products you've been using and can understand the need to vent. Unreal Engine has proven to be a very difficult codebase for us to get right, but we do have some engineers working specifically on those scenarios right now. I'll pass your feedback along to the folks who are working on trying to make the Unreal Engine development experience better.

drakgoku commented 1 year ago

For Unreal Engine projects.

A possible idea: Optimize memory usage and header file processing by Intellisense like creating or modifying the caching or indexing technique, so that you don't have to recalculate all the headers for each change. Simply check that "scope was changed", then it would only apply that update to that scope.

For example, The project consists of many folders. Although for the project two folders are normally used: "Engine" (UE functionality that all classes implement) and "Games" (the project itself).

The "Engine" should only be scanned once (When you open the project with VSC). It is very rare that you modify something of the "Engine". Although it is possible. It would have to detect that if the Engine was changed, then rescan and rebuild the entire project for each change. In this case, when the project is rescanned / rebuilt, the 20 seconds are justified since I detect a big change in the "Engine".

The benefits would be:

No unnecessary scan in the "Engine" folder that wastes a lot of time.
Small changes: Modifications in the Games folder "Rescan only the Games folder", shortening the Intellisense to update in less than 1 sec.
Medium Changes: if the user has modified any config file then he will have to rebuild the project again.
Big Changes: Modifications in the Engine folder "Rescan / rebuild the whole project".

Obviously, if any config file is modified, you will have to rebuild the project.

It would also help a lot to have a build or rebuild button. Since the user could add an extra configuration file to the project and instead of opening, closing or rebuilding the project for each change, they could do it manually. I leave the use case to you as it suits you.

Note: If rebuilding the entire project takes longer, it's normal, that's because it will depend on the computer, project and VSC code optimization to update the internal references.

bobbrow commented 1 year ago

A possible idea: Optimize memory usage and header file processing by Intellisense like creating or modifying the caching or indexing technique, so that you don't have to recalculate all the headers for each change. Simply check that "scope was changed", then it would only apply that update to that scope.

We actually do this already. If you use precompiled headers, it generally works really well until you change something in the precompiled header which triggers a full reparse. These cached precompiled headers can be reused across various source files (translation units) in your project. If you don't use precompiled headers we pretend that you do so that we can still do the caching, but those can't be shared across translation units.

We then also do a "fragment parse" which should just cover the areas that you've modified, but after a certain number of edits, the system needs to reset to flush out all the intermediate allocations it's made over time and a full reparse happens again. Again, in the general case this works pretty well, but Unreal Engine needs more specific tuning because it's so big and we have folks trying to move the needle there (it's harder than you suspect).

drakgoku commented 1 year ago

I am afraid to tell you that it does not seem to work or is not correct in this case, as I well show.

According to my video https://imgur.com/qTjLCKS, I'm just modifying basic aspects of a basic .h header inside the "Games/" folder. In that example in the Games folder, I only have 4 C++ files (2 .h and 2.cpp). I just modify the .h or test the IntelliSense with the variables (I don't do anything else)

Usually works great until you change something in the precompiled header that triggers a full scan.

There is nothing that would trigger a precompile modification and have to parse the entire project. It's just a class. Although it is true that it has a .generated, "it" is only generated when the project is executed. "The .generated.h file contains code automatically generated by the Unreal Engine to facilitate integration between C++ and the reflection system" Wouldn't it be possible to avoid rescanning the entire project in this case and just check if the syntax is correct?

I would also like an explanation or proof of how "chunk analysis" is done and how it determines when to reboot the system to remove intermediate allocations. What criteria or algorithms are used? Do you have any evidence or data that shows how this method works?

I would like to see the evidence or data on that.

bobbrow commented 1 year ago

There could be a bug for this case of editing your header or it could be that the parser failed to create the automatic PCH. We'd have to investigate. Did you happen to change the C_Cpp.intelliSenseCacheSize setting to 0 at any point?

drakgoku commented 1 year ago

I tried every way the extension has including intelliSenseCacheSize.

If I set intelliSenseCacheSize to 0 (it's answered in my third post)

"Now the .cpp takes 15 seconds to detect it or a simple modification."

It was very slow with any type of modification in either .cpp or .h. I also seem to remember that I tested the cache and memory at "16384 MB" but there was practically no impact.

bobbrow commented 1 year ago

Then my suspicion is that that the header you edited was made a part of the "fake" PCH that we create for your source file.

If your project does use explicit precompiled headers, then Visual Studio has support for the behavior I described earlier (where IntelliSense can reuse your PCH's across multiple translation units and you have more control over which headers are considered part of the more stable PCH). We do not yet support that behavior in VS Code.

drakgoku commented 1 year ago

If I had the time, I'd clone the code and look at the source code for the VSC C++ extension (with Typescript and C++ most likely) and do a pull request myself with that improved functionality. But I don't have time, and it seems that Rider has that functionality.

Much encouragement. I hope my great-grandchildren can have that functionality.

bobbrow commented 1 year ago

The part of the codebase that controls this behavior is not open source. We are working on performance improvements that will benefit Unreal Engine developers. They are not as simple as you may think they are. But I don't expect that your great-grandchildren will have to wait for it... Of course, you are welcome to use Rider for now if it is working better for you.

drakgoku commented 8 months ago

How are you handling it? Can I ask or really not?

I'm on Rider and it consumes more than a coffee maker without coffee. Anyway, I hope you have at least made some progress. My grandson may not be as picky as me and compile from a notepad... better yet, from an EDLIN.

bobbrow commented 8 months ago

We have been working on some improvements to the "fragment parse" cases prioritizing visible code sections that we hope to share in a pre-release of 1.19 in early January. We have not tested with Unreal Engine at this point (again, we recommend VS for Unreal Engine development) so right now I can't say whether it will fix the 15 second delays mentioned earlier, but for editing within function bodies it should feel a lot quicker.

malkaviano commented 4 months ago

Still hoping for an improvement on this to work with UE.

yg-i commented 3 months ago

My problem is that any operation that requires intellisense tends to trigger a popup in the bottom right corner saying "Find All References: X/Y files confirmed". Screenshot below. Is this caused by the same problem causing this issue?

microsoft / vscode-cpptools