Intellisense performance (part 2)

Sysprogs forums Forums VisualGDB Intellisense performance (part 2)

Viewing 13 posts - 1 through 13 (of 13 total)
  • Author
    Posts
  • #10809
    Ophidian14
    Participant

    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.

    #10816
    support
    Keymaster

    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).

    #10864
    Ophidian14
    Participant

    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]

    #10869
    support
    Keymaster

    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?

    #10962
    Ophidian14
    Participant

    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.

    #10963
    Ophidian14
    Participant

    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?

    #10964
    thedixon
    Participant

    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.

    #10965
    Ophidian14
    Participant

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

    #10976
    support
    Keymaster

    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).

    #10981
    Ophidian14
    Participant

    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.

    #10990
    thedixon
    Participant

    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.

    #10992
    support
    Keymaster

    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.

    #11610
    support
    Keymaster

    Hi,

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

Viewing 13 posts - 1 through 13 (of 13 total)
  • You must be logged in to reply to this topic.