Intellisense performance for newly opened files

[Ophidian14]

Hello,

In my project I have many source files (say, 100 or so).  I created my project by importing from my Makefile, and after a few tweaks to my build commands and path mappings, Intellisense mostly works for files that I am actively editing.  By actively, I mean, the file in question has been the foreground tab in Visual Studio and I have been editing it for awhile, and triggered other Intellisense popups previously by doing -> or .  .

However, say I open a new .cpp source file somewhere in my solution, navigate to a random (non-static) class member method definition, add a few blank lines, type “this->”, and wait.  Almost always, nothing will appear right away.  When I look in task manager, CppHostEngine.exe *32 cycles from ~150MB memory usage up to ~500MB and back down a few times, all while using 100% of one core.  If I retype “this->” several more times over the next minute or so, eventually I will get the Intellisense popup but not until at least 30-45 seconds have passed.  After this, Intellisense will work almost immediately, but only inside of this file.  Therefore my questions are as follows.

1.  Is this the normal/expected behavior?
2.  In “normal” Visual C++ projects, the Intellisense “always” works “immediately” upon entering a new file and performing the same set of steps.  If #1 is the expected behavior is there a way to get the performance like a traditional VisualC++ project?
3.  What’s going on when CppEngineHost*32.exe is “cycling” its memory usage and CPU during this time?  After I open a new project, I see VS “cataloging” all of the files in my project;  isn’t this for the purpose of subsequent speedy Intellisense usage?

Thanks for any help you can provide.

[support]

Hi,

This behavior is somewhat by design. The Clang IntelliSense aims for high accuracy, so it needs to fully parse the source file before it can do code suggestions. If the file was modified in the last 24 hours, VisualGDB considers it to be an actively edited file and creates a “preamble” – precompiled snapshot of the header files used by the file, so subsequent IntelliSense operations work very fast. The high CPU usage by CppEngineHost.exe is normal – this is the process that hosts the IntelliSense engine (we don’t run it inside Visual Studio so that Clang crashes would not crash Visual Studio itself).

You can see what exactly is going on via the View->Clang IntelliSense Diagnostics Console.

In our tests, the first parse usually took 3-6 seconds, but never 35-45. Could you let us know which hardware you are using? Also if your project is located on a network drive, please consider copying it locally as accessing many .h files over network will be very slow.

Another optimization tip we would give is to use precompiled headers. If VisualGDB detects that over 80% of the project files include the same header file at the beginning, it will automatically treat it as a precompiled header, greatly reducing the parse time for new files, even if your build system does not support precompiled headers and is treating it as a normal header file.

[Ophidian14]

Okay, thanks for explaining how things are working under the covers.  Would it not be feasible to keep an up-to-date parse of each file somewhere?  I thought that’s what the “initial scan” was when you open a project “fresh” and the .db and Cache/ folders/files are not existing, but it seems like those don’t do anything.

My workstation is a dual E5-2630 workstation with 16GB RAM.  The source files are over the network, but is it safe to assume that if CppEngineHost is at 100% of one core it’s not being I/O limited?  I would try copying the source files locally again, but when I last did it, the “copy back to build server” step made a huge mess of everything.  I have my own custom Makefile living on my build server, which is where all the files live (in source control) so it’s just easier to have everything “remote” and view the files over Samba.

In terms of the performance, I am dealing with a code base that makes heavy use of Boost, templates, and very little use of pImpl and other build-speed-increasing tricks so I’m not surprised that the initial parses take so long.  At least now that I know what’s going on I can sort of plan my workflow accordingly to not incur the delays so frequently.

I can’t touch all the source files in my project to add a precompiled header #include so what I’ve been doing is using the -include-pch option to Clang to sort of “force include” my own “standalone” precompiled header.  This helps in build times, but obviously VisualGDB can’t see that.

[support]

Hi,

VisualGDB normally does not prebuild the full IntelliSense information for all sources, as this takes a lot of space (a full uncompressed cache for the entire Linux Kernel is around 50GB) and normally if precompiled headers are detected properly, the delay you describe should not happen. It does build a highly optimized reference cache, but it’s only used in “Go to definition” and “Find all references” commands.

What we could offer is add a setting to forcibly precompile and include an arbitrary header file as if it was directly included from each source. Would that be helpful?

It also sounds like a good idea to measure how much time was spent compiling each header and offer such optimizations automatically, so we will experiment with this in v5.3.

 

[Author]

Posts