VC++ IntelliSense Engine and PCH

[JFreyberger]

Hi again,

sorry for all my posts but I just started working with VisualGDB and I really like it (mainly because of it’s support for cross compilation on my windows machine for a raspberry PI in combination with precompiled headers) but I still see some problems. So the new IntelliSense Engine coming with VisualGDB really slows down working in VisualStudio and menu commands like “Goto Definition” or “Goto Declaration” most time don’t respond at all. VisualStudio constantly suggests to deactivate the VisualGDB extension as it also detects that it’s unresponsive for up to a minute due to this extension. So I decided to switch back to the normal VC++ IntelliSense. Unfortunately this also doesn’t work and it says it cannot create the precompiled headers and so I only see lots of errors although my code compiles correct. I think these problems may be related to the use of Boost Beast inside my project which is notorious for it’s extensive use of nested templates etc. but in standard Windows Visual C++ project it works correct. Do you have any tip for me how I could get the IntelliSense performing better?

Thanks and best regards,

Johannes

[support]

Hi,

No problem, we have a detailed tutorial on optimizing Clang IntelliSense performance: https://visualgdb.com/tutorials/intellisense/performance/

[JFreyberger]

OK, I tried to follow these steps … unfortunately this ended in a Clang IntelliSense Engine crash (see attached bitmap)

Attachments:

You must be logged in to view attached files.

[JFreyberger]

And another little thing: my compiler says

pch.h:1:9: warning: The precompiled header file should use an include guard, not #pragma once.

The page you pointed me to recommends the use of #pragma once.

• This reply was modified 3 years, 1 month ago by JFreyberger.

[support]

Hi,

Clang IntelliSense works differently from the regular VC++ IntelliSense. The regular Visual Studio’s IntelliSense parses the code using a faster, but less accurate method. This results in faster initial performance for huge projects, but produces less accurate results for complex cases.

The Clang IntelliSense always does a 100% accurate parse of the code (as if it was being compiled), and hence can extract precise information about the code structure, powering features like CodeJumps, Code Explorer, etc. Due to the complexity of the Clang codebase, it indeed sometimes crashes when it encounters incomplete code. Our IntelliSense engine is designed to seamlessly recover from these crashes without losing any data, so you can continue developing your project as usual, even if the engine has crashed. If it repeatedly crashes at exactly the same position, please feel free to attach the dump file it produced here, and we will investigate it further.

The #pragma once warning issued by Clang can be safely ignored. Alternatively, you can indeed switch to using include guards if you wish to eliminate the warning.

[JFreyberger]

Hi,

thanks for your quick response. Although the times shown in your special popup for parsing the headers etc. by Clang IntelliSense seem quite good it sometimes takes several seconds to invoke Goto Definition/Declaration and also Declaration and Defintion seem to be mixed up. Sometimes it doesn’t work at all. Unfortunately the regular VC++ IntelliSense also doesn’t work as expected and as I’m used to it from my normal VC++ projects. There seems to be a problem around the pch file which cannnot be created correct. Could it be that VisualGDB breaks the regular VC++ IntelliSense for Linux projects?

[support]

Hi,

The regular VC++ IntelliSense is implemented by Visual Studio itself. VisualGDB provides it with the list of include directories and preprocessor macros from your projects, but it cannot control how it handles things internally. Depending on the project structure (or some project-specific parameters) it indeed may not work correctly. This was one of the reasons we developed the Clang IntelliSense as a replacement to it.

If you can point out specific cases where the Clang IntelliSense doesn’t work as expected (e.g. Go to Definition not working), we can gladly investigate it further.

In general, Go to Definition requires an up-to-date symbol cache (i.e. list of all symbols and relations between them). It usually takes a few minutes to build initially, but unless you frequently change the common headers used by all other files, accessing it should be almost instantaneous. Again, if you can provide a few examples when it’s not working this way (with the rough timing or a screen recording), we will be very happy to look further into it and help you get it working.

[JFreyberger]

Hi,

now I’ve activated the Clang log and I see lots of entries like this:

[+8:04:16.864] Starting operation: Reparsing C:\User_jof\CPP_LINUX\R3layPI\AudioManager.cpp
[+8:04:17.236] Starting operation: Parse – HighlightBraces
[+8:04:17.237] Operation completed: Parse – HighlightBraces [0 msec]
[+8:04:17.454] Starting operation: Reporting 153 + 0 extra sources to Clang engine…
[+8:04:17.455] Operation completed: Reporting 153 + 0 extra sources to Clang engine… [0 msec]
[+8:04:17.456] Failed to write to an IPC Port: Die Pipe wird gerade geschlossen.
[+8:04:17.456] while trying to parse C:\User_jof\CPP_LINUX\R3layPI\AudioManager.cpp
[+8:04:17.456] Stack trace:
[+8:04:17.456] Server stack trace:
[+8:04:17.456] at System.Runtime.Remoting.Channels.Ipc.IpcPort.Write(Byte[] data, Int32 offset, Int32 size)
[+8:04:17.456] at System.Runtime.Remoting.Channels.Ipc.PipeStream.Write(Byte[] buffer, Int32 offset, Int32 count)
[+8:04:17.456] at System.Runtime.Remoting.Channels.ChunkedMemoryStream.WriteTo(Stream stream)
[+8:04:17.456] at System.Runtime.Remoting.Channels.StreamHelper.CopyStream(Stream source, Stream target)
[+8:04:17.456] at System.Runtime.Remoting.Channels.Ipc.IpcClientHandler.SendRequest(IMessage msg, ITransportHeaders headers, Stream contentStream)
[+8:04:17.456] at System.Runtime.Remoting.Channels.Ipc.IpcClientTransportSink.ProcessMessage(IMessage msg, ITransportHeaders requestHeaders, Stream requestStream, ITransportHeaders& responseHeaders, Stream& responseStream)
[+8:04:17.456] at System.Runtime.Remoting.Channels.BinaryClientFormatterSink.SyncProcessMessage(IMessage msg)
[+8:04:17.456] Exception rethrown at [0]:
[+8:04:17.456] at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
[+8:04:17.456] at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
[+8:04:17.456] at np.l3(z3 a)
[+8:04:17.456] at k02.t1(ps1 b, ay2 a)
[+8:04:17.456] at k02.h4.b(ps1 a)

[support]

This happens when the Clang IntelliSense process crashes and VisualGDB automatically restarts it. If it always happens after a “Reparsing C:\User_jof\CPP_LINUX\R3layPI\AudioManager.cpp” line, please feel free to attach a dump file produced after the crash, and we will investigate it.

[JFreyberger]

Hi,

things really seem to have stabilized a lot since I rebootet my machine. So meanwhile Clang IntelliSense runs stable and shows valid results. One remaining thing is still the “thinking break” of 5-8 seconds when I invoke Goto Definition/Declaration. In the Clang IntelliSense Log this looks like the lines below (I have changed the filename just for this post, please see the 6 second break before “Starting operation: Exporting parse results”)

[+3:53:22.526] GoTo request: GotoDecl
[+3:53:22.526] Preparing for GoTo parsing
[+3:53:22.526] Starting GoTo parsing
[+3:53:22.526] Starting operation: Parse – Goto
[+3:53:22.527] Starting operation: Reparsing C:\xyz\xyz.cpp
[+3:53:22.530] C:\xyz\xyz.cpp has not changed since last build. Doing a quick recheck…
[+3:53:22.675] Checking if any PSFs for C:\xyz\xyz.cpp are outdated…
[+3:53:22.778] No changed PSFs found. Doing a CodeComplete run with minimal reparsing.
[+3:53:22.884] Checking if any PSFs for C:\xyz\xyz.cpp are outdated…
[+3:53:22.975] No changed PSFs found. Doing a CodeComplete run with minimal reparsing.
[+3:53:28.676] Starting operation: Exporting parse results
[+3:53:28.676] Checking C:\xyz\xyz.cpp for missing headers…
[+3:53:28.676] No missing headers for C:\xyz\xyz.cpp.

[support]

Hi,

Thanks for the update. The delay between “Doing a CodeComplete run with minimal reparsing” and “Exporting parse results” is the time that Clang takes to parse the source file and determine the symbol referenced at the requested location.

Normally, it should take roughly the same time as the regular code completion (Ctrl-Space) does, that is typically under 1 second. If it takes longer, most likely, the precompiled headers or preambles are not working properly. We can help you get it working if you could check a few additional things:

1. Does the IntelliSense timing view (step 7 of the tutorial) show anything extraordinary? Could you share a screenshot of it?
2. Does code completion (Ctrl-Space) work faster that Go-to-Definition? Is the speed the same for unscoped completion (e.g. int main() { <HERE> }) vs. scoped completion (std::<HERE>)? Could you attach the snippets from the Clang IntelliSense log corresponding to the scoped and unscoped code completions?

[JFreyberger]

Hi,

I’ve attached a screenshot of the parsing times. Actually I’m already using precompiled headers – that was one of the reasons to switch to VisualGDB. But I’m also the one who patched cc1plus.exx to work with big precompiled headers (see: https://sysprogs.com/w/forums/topic/cc1plus-exe-crash-when-using-large-precompiled-header-file/ ). So probably it’s a performance problem due to my large pch file (my pch.h-CXX.gch has a size of 338 MBytes). Unfortunately I also observer long times (30 secs and more) when starting a debug session and when the breakpoints are set (>10 secs) which are probably also related to the size of the pch file and the project at all. And I’m not really sure how I could solve this, as the vast majority of the pch size comes from the use of boost and especially boost::beast and it’s extensive usage of templates. But on the other hand I think boost beast is really worth using it and it’s a stable and modern code base.

Best, Johannes

Attachments:

You must be logged in to view attached files.

[support]

Hi,

The IntelliSense-level precompiled headers are different from the GCC precompiled headers. The please make sure you explicitly configure Clang IntelliSense to use pch.h as a precompiled header file as shown in step 11 of this tutorial.

The slow debugging performance likely comes from gdb itself. You can verify it using the timing view in the GDB session window and you might be able to speed it up by using symbol indexes.

[JFreyberger]

Thanks for your suggestions. The settings according to step 11 didn’t really help so much, the time is now just spent somewhere else – see screenshot. (Do I have to enable the lightweight analyse for each file separately)

And I’ve also added some screenshots around the start of a debugging session. I think the main cluprit really is the boost beast which I’m using for my webserver. Even setting a breaking there takes several seconds. Other small test projects also using boost asio but without boost beast perform really fine.

Attachments:

You must be logged in to view attached files.

[support]

Hi,

The “Analyzing references” stage only affects advanced recoloring of the source file, finding references, etc. You can indeed enable lightweight references analysis if you would like to speed it up.

Code suggestions and go-to-definition use a different mechanism that does not involve the “Analyzing references” part.

The debug log looks like the delay comes from gdb and not from VisualGDB itself. Hence, it will affect any debug session that is using gdb and cannot be reduced on the VisualGDB side.

[Author]

Posts