Intellisense performance (part 2)

[Ophidian14]

Hello, recently I posted on this forum about Intellisense performance.  I appreciated the insight into the program’s functionality as given in the response post.

I am wondering if anything else can be done to improve the performance, such as an experimental build of CppEngineHost that has optimizations, etc.  Some of the source files I have are impossible to use with VisualGDB due to performance.  For example, I have a file that consistently takes over 60,000ms to parse (per the Clang Monitoring Console or whatever it’s called) and while this is happening, the source file seems to be locked so I can’t save any modifications.  But as soon as I wait and save, the process begins again and the file is locked another 60 seconds.  Other problems I have include CppEngineHost crashing multiple times per day and the GUI freezing sometimes when the debugger breaks in.

In a prior post one of the suggestions was to allow a hand-edited /  user-supplied precompiled headers #include file to cut down on the cruft.  I think this would be a good start.  I would like to beta test such an idea if it were made available.

Thanks for any consideration you can provide.  BTW I did buy a license and truly enjoy the program, it is a lifesaver for me but there are some rough edges around it when the source base has excessive use of Boost and no pImpl/forward declarations etc.  VisualGDB is still a far better alternative than i.e. Eclipse CDT which just crashes immediately upon opening the code base.

[support]

Hi,

Thanks, we will update this post once the support for handcrafted PCH file is available. In the meanwhile feel free to attach the logs from the Clang IntelliSense Diagnostics Console showing the slow parse and we can advise you on possible workarounds (it usually happens then VisualGDB fails to cache rarely modified parts of the files properly).

[Ophidian14]

Here is an example of a slow parse (~28 seconds, sometimes it’s 70+).  What to do?  It doesn’t seem like there’s enough actionable information in this log snippet.

 

[+1:23:50.800] Starting operation: Reparsing \\10.10.161.129\build\cfa\Laser\Laser\Test1.cpp
[+1:23:51.023] Post-PSF state of  is outdated. The file will be reparsed
[+1:23:51.038] \\10.10.161.129\build\cfa\laser\laser\test1.cpp has changed since last build. Doing full analysis..
[+1:23:51.038] PSF 0 (normal preamble) does not match main file. It will be re-built
[+1:24:18.483] Starting operation: Exporting parse results
[+1:24:18.713] Operation completed: Exporting parse results [230 msec]
[+1:24:18.713] Checked \\10.10.161.129\build\cfa\Laser\Laser\Test1.cpp: 2 error records
[+1:24:18.816] Operation completed: Reparsing \\10.10.161.129\build\cfa\Laser\Laser\Test1.cpp [28016 msec]
[+1:24:18.821] Operation completed: Parse – Check [28023 msec]
[+1:24:18.936] Starting operation: Parse – HighlightBraces
[+1:24:18.937] Operation completed: Parse – HighlightBraces [0 msec]

[support]

Hi,

The log actually shows that VisualGDB rebuilds the entire file instead of reusing the precompiled part. Can you confirm that you see the “PSF 0 (normal preamble) does not match main file.” message even after small localized changes?

Another clue here is that your source code is located on a remote system. Network can introduce significant delays when reading many small files (due to latencies) and that can significantly impact the parse time. Could you try moving the sources on the Windows side and checking if it makes things faster?

[Ophidian14]

I guess it depends what you mean.  If I make a one line change, and then resave the file, I see this:

[+0:12:24.859] Starting operation: Parse – Check
[+0:12:24.862] Starting operation: Reparsing \\10.10.161.129\build\cfa\Laser\Laser\Test1.cpp
[+0:12:25.082] Post-PSF state of  is outdated. The file will be reparsed
[+0:12:25.098] \\10.10.161.129\build\cfa\laser\laser\test1.cpp has changed since last build. Doing full analysis..
[+0:12:25.291] No changed PSFs found, but \\10.10.161.129\build\cfa\laser\laser\test1.cpp is outdated due to itself. Doing a quick PSF-based rebuild with 1 PSFs
[+0:12:31.692] Starting operation: Exporting parse results
[+0:12:31.692] Checking \\10.10.161.129\build\cfa\laser\laser\test1.cpp for missing headers..
[+0:12:31.692] No missing headers for \\10.10.161.129\build\cfa\laser\laser\test1.cpp
[+0:12:31.930] Operation completed: Exporting parse results [237 msec]
[+0:12:31.930] Checked \\10.10.161.129\build\cfa\Laser\Laser\Test1.cpp: 0 error records
[+0:12:32.014] Operation completed: Reparsing \\10.10.161.129\build\cfa\Laser\Laser\Test1.cpp [7151 msec]
[+0:12:32.029] Operation completed: Parse – Check [7169 msec]
[+0:12:32.137] Starting operation: Parse – HighlightBraces
[+0:12:32.137] Operation completed: Parse – HighlightBraces [0 msec]

 

Is that in line with what you would expect?

With regards to having the source files on a Samba share.  Ultimately I have to build this source on a Linux machine that has an environment setup that is very particular in nature.  I can’t cross-compile on Windows, there’s no way it would work.  I tried the option to keep the source files locally and copy them when it’s time to build, but my codebase is extensive and it didn’t seem to detect which files were changed.  This resulted in it spamming massive amounts of unchanged files into my git repository on the remote box and everything more or less got hosed.  That’s why I’m doing it this way for now.

[Ophidian14]

Also, usually when everything’s being slow, CppEngineHost*32.exe is running at 100% of one core, so is it really network I/O bound if this is happening?

[thedixon]

Pardon to barge in, but I discovered the same issue with sending a lot of files back to the remote machine. Good news is – it only happens once after the initial import, after that it works fine, so you can use it. Bad news is it doesn’t change the performance a bit, it’s cpu bound.

[Ophidian14]

Okay, thanks for confirming, that’s what I thought.  And interesting about the mass import.

[support]

Hi,

Those are actually 2 different processes. The long one-time indexing (that uses all CPU cores) happens one time after you import a project and builds a large database of all cross-references in your code, so you can instantly execute commands like “Find all references”. The 7169 msec check mentioned in the log file above only checks one single source file and should normally happen in the background and not cause any delays (as long as you are using v5.2, code completion and other IntelliSense functionality can run in parallel with the long “Parse – Check” operation).

[Ophidian14]

Okay.  Well is there any way I can register to be a beta tester (or something like that) for the “user supplied” precompiled header file?  Or is there any other way I can assist in bringing it to readiness?  Thanks in advance.

[thedixon]

I actually have another suggestion to improve performance, which could be potentially easy to implement? Currently when VisualGDB decides to reparse the file, all the browsing info is unavailable. Perhaps old database could be used while new one is being generated? Yes, it won’t be perfect, but it will often be quite good.

[support]

Hi,

VisualGDB 5.2 should already be doing double-buffering for the parse data. I.e. while a file is being parsed, it will use the previous parse data to highlight local references and handle other similar functionality. The Ctrl-Space code completion should also work completely parallel to this. If you observe the opposite, please share the repro steps and the diagnostic log so that we could investigate this.

Ophidian14: we will try to include this feature in one of the early preview builds of v5.3. We will post an update here once it becomes available.

[support]

Hi,

OK, we have added support for IntelliSense-only precompiled headers to VisualGDB 5.3 Preview 2.

[Author]

Posts