Forum Replies Created
-
Posts
-
I would but Dropbox and Google Drive are blocked at my work. Do you have any suggestions about which hosting site I might use besides those.
I have the debug build and am trying to reproduce.
Thank you for contacting us.
A support ticket request (#136123) has been created and a representative will be getting back to you shortly if necessary.
Support Team
Thank you for contacting us.
A support ticket request (#673066) has been created and a representative will be getting back to you shortly if necessary.
Support Team
Sorry, I think I see the problem now. I was submitting tickets with Firefox and getting Javascript errors and no confirmation page. Submitting a test ticket through Chrome succeeded.
Okay I also submitted a second ticket immediately after the first ticket, simply asking if the first was received. You didn’t receive that one either? I will try contacting the support email.
Sorry, did both of those things but still crashing. I’ve collected a file “WERA71D.tmp.hdmp”, 227MB. Can I make it available somehow?
Okay. On preview 2 I am seeing repeated crashes in CppEngineHost but I don’t have the opportunity to submit a trouble report unlike before.. I just get the attached crash. What’s the best way to get you information?
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.
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?
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.
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]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.
