VisualGDB slow

[gaminn]

Hi,

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?

[support]

Hi,

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.

[devrope]

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

• This reply was modified 4 years, 9 months ago by devrope.

[support]

Hi,

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.

[devrope]

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.

[devrope]

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 🙁

[support]

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:

1. 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?
2. 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?
3. 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?

[devrope]

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.

[support]

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-5.5.3.3470.msi

[devrope]

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.

[devrope]

Looks like the new logic for analyzing linker messages was working slower than expected for long build command lines.

This bug seems to be back again in v5.5.7.3679 (and also in the offical preview 7).
Build is slow, and after build the studio is sluggish for a while.
I also disabled all coloring in the settings, but I’m still getting some white rows.
BTW: I’ve set it to output only to the normal output window.

[support]

No problem, we can investigate it. Do you mind attaching an updated build log so that we could retest it on our side?

Edit:  you can also try running the following command yourself:

VisualGDB.exe /scanlog [build log file]

It will run every line of the build log through VisualGDB’s build message regexes and will display a detailed timing report.

[devrope]

Attached is the build log.
This time it’s not so much a slow build, but after the build, VS is sluggish/not responding for a while.
When I try to scroll in the Output window it hangs. Also the Output window is coloring some rows white even though I disabled all Advanced build things, and redirected it to the normal Output.

Attachments:

You must be logged in to view attached files.

[support]

Strange. Just for the record, we have tried running VisualGDB /scanlog on the file you attached, but it only took ~100 msec, so the problem must be elsewhere.

Also it’s hard to say whether you are using the regular output, or the advanced output window. Please attach the screenshots of the output window and the settings where you disabled the advanced output (make sure you restart VS after changing the output settings) so that we could see what is going on.

Also please try narrowing down the slowdown, e.g. whether it happens:

• On first build after starting VS or after some time
• With any project, or only a specific project type
• With any amount of output, or only if the build produced large output amounts

Additionally, if you could make a quick screen video showing the problem, we might be able to narrow it down faster.

[devrope]

I mentioned that I use the regular Output (see attached), same as last time I had issues.
It happens all the time, any VGDB embedded project, any amount in the output.

It seems that all gcc-rows in the output are colored white, even though I disabled coloring.
And then when I scroll in the Output and the white rows are shown, everything in VS gets sluggish.

Attachments:

You must be logged in to view attached files.

[Author]

Posts