January 27, 2019 at 19:04 #23599
I created nrf52832 sample project, made some changes to it (new files, new include paths etc) and now, the build process in Visual Studio is very slow. It is compiling every single .c file for about 6 seconds (watching Output window). When I run make command in the project’s folder it compiles in fraction of time. Also if I create sample nrf52832 project and build it in Visual Studio, it compiles quickly.
What can cause the slow compile issue?January 28, 2019 at 05:19 #23600
Unfortunately it’s hard to say what exactly is wrong without knowing the details. Is the imported project using MSBuild, VisualGDB-generated Makefile, or a 3rd-party Makefile? Please also try isolating just one file compilation task (i.e. modify one file and count exactly how much time does it take during VisualGDB-controlled build vs. when running gcc manually). If you are using a custom Makefile, please modify it to start a cmd.exe instance in a new window (using the ‘start’ command) and then try running gcc or make from that window. If it also builds slowly, it could be caused by some environment variables inherited from Visual Studio.
It could also be helpful to temporarily disable your antivirus or trying to use a different disk, as buggy antivirus software or disk errors could cause seemingly random slowdowns.January 23, 2020 at 10:18 #27212
I’m having the same issue, after upgrading to VisualGDB 5.5 Preview 2 (also tried preview 3 build 3457).
I wanted to try the new “Memory utilization report from Linker script” and made no changes at all to my code, except enabling the new option.
My project is nRF52832 generated from VGDB with make file (not msbuild) and in v5.4r12 it builds fast.
Also, the new mem utilization isn’t correct, so there’s that too 🙁
My linker script is the one you provide, with reserved space for SoftDevice (nRF52832_XXAA_S132_reserve.lds), and the report states:
——————- Memory utilization report ——————-
Used FLASH_SOFTDEVICE: 57KB out of 152KB (37%)
Used FLASH: 876 bytes out of 324KB (0%)
Used SRAM_SOFTDEVICE: 612 bytes out of 30KB (1%)
Used RAM: 4580 bytes out of 33KB (13%)
That’s not correct, right?
Will revert to 5.4r12 for now, as it takes 11 minutes to build (used to take ~1 minute).
January 24, 2020 at 02:16 #27242
- This reply was modified 1 month ago by devrope.
Strange, the build-related logic of VisualGDB 5.5 has not changed compared to 5.4 (with the exception of the new build output window).
If you can confirm that installing v5.4 back increases the build speed, please try disabling the advanced build output (Tools->Options->VisualGDB->Advanced Build->Show build output from VisualGDB = Regular VS Output Window) and restarting Visual Studio. If it helps, please let us know and we will investigate what could be causing the slowdown. If it doesn’t help, please let us know if you are using GNU Make or MSBuild and also try checking if disabling the antivirus speeds up the build.
Thanks for pointing out the memory utilization bug, it was indeed shown incorrectly for adjacent memories. We have fixed it in VisualGDB 5.5 Preview 3.January 24, 2020 at 09:11 #27244
Before reverting yesterday I tried to disable the new “advanced build output” but it didn’t help.
The one thing I didn’t do was restarting Viusal Studio.
After reverting to 5.4 the build took 45 seconds, so disabling AV seems pointless.
The project is using GNU Make.
Regarding the mem utilization fix: is it fixed in the real preview 3 (3458)? Because I tried 3457 and it was still wrong there.January 24, 2020 at 10:36 #27245
After installing 3458 (the official Preview 3) I can confirm that it still builds very slow (11 min instead of 45 secs).
I tried “disabling the advanced build output (Tools->Options->VisualGDB->Advanced Build->Show build output from VisualGDB = Regular VS Output Window) and restarting Visual Studio”, but it didn’t help.
No code/project changes at all between tries.
Will revert to 5.4 once again 🙁January 24, 2020 at 17:50 #27247
Thanks for checking everything. The memory utilization computation was the last fix that went into Preview 3, hence it is indeed only present in that specific build.
If you are using GNU Make, the build results should normally be completely the same, since all VisualGDB does is launches make.exe in the project’s directory.
In order to troubleshoot it, please do the following:
January 29, 2020 at 14:36 #27282
- Try comparing the fast and slow build logs. Is there any difference? Does VisualGDB 5.5 consistently rebuild all files, while VisualGDB 5.4 only build changed files?
- What happens if you run VisualGDB.exe /build … (see the VS Output window for the full command line) manually from the Command Prompt? Is the build still slow?
- What happens if you run make CONFIG=Debug (see the VS output window for the command line again) in the project directory (you may need to set BSP_ROOT and TOOLCHAIN_DIR via environment)? Does it also build slowly?
1. The build logs are the same essentially, please see attached. Every compile row takes ~6 seconds when using VGDB 5.5 and it’s devenv.exe process that takes ~25% CPU.
2. Same thing, still slow. Every compile row takes ~6 seconds when using VGDB 5.5 and it’s VisualGDB.exe process that takes ~20% CPU.
3. Builds fast! 🙂 But makes VisualGDB kind of redundant… and no mem utilization report, of course 🙁
Attachments:You must be logged in to view attached files.January 29, 2020 at 20:23 #27292
Thankfully, VisualGDB has much more to offer than just a shortcut for launching make.exe 🙂
Either way, thanks for the log files. Looks like the new logic for analyzing linker messages was working slower than expected for long build command lines. We have optimized it in the following build: VisualGDB-220.127.116.1170.msiJanuary 30, 2020 at 09:21 #27297
Sorry, but the 3470 installer is corrupt, see attached picture.
Not knowing if there was a later build, I tried changing the url to 3471, and there was!
This time the installation went fine, and… it’s building fast again! 🙂
And the new mem report is really nice.
Used FLASH_SOFTDEVICE: 0 bytes out of 152KB (0%)
Used FLASH: 53KB out of 324KB (16%)
Used SRAM_SOFTDEVICE: 0 bytes out of 30KB (0%)
Used RAM: 4840 bytes out of 33KB (14%)
Thanks for the fast bugfix, now back to coding!
Attachments:You must be logged in to view attached files.
You must be logged in to reply to this topic.