I don't understand this issue, but it happens on both of my computers where I use VS and Arduino plugin. This is specific to VS2015. I am running the latest version of the plugin, which was updated today. (I can't remember how to find plugin version number)

Basically when I switch between debug and release, or switch to another computer where there have been significant enough changes since the last build, or sometimes it will do it EVERY time I build the debug version, VS hangs and it will take over 30 seconds to compile what usually takes about a second.

Quote:


But if I build it again, I get this:

Quote:


Which is more what I expect.

While this is happening, VS will hang 100%. Can't make any changes to code. Can't look at other menus. Can't cancel the build. It's frustrating to have to wait 30 seconds for it to compile. I also notice that this happens more often in Debug than it does in Release. It was so bad at one point that I was finding that it took me less time to debug in release mode than in debug mode because I didn't have to wait 30 seconds each time I would compile.

For the record, both of my machines are extremely beefy. No messing around here. i7 6-core processors, and LOTS of memory. I don't have these issues compiling any of my .Net apps.

Any ideas?

For the record, everything is on a SSD (500MB/sec read 400MB/sec write) on both computers, and virus software does not exist.

I just turned on verbose messages and it still hangs, but I am seeing the hang between two compile events. It is related to the u8g display library. It hangs between compiling u8g_font_data.c.o and u8g_line.c.o. I'm just not sure if the print to the output is occurring before or after the command is executed. I'm going to assume it's the u8g_font_data.c.o file because it's almost 1.4MB, compared to most other files that are just a few KB. But when I run that compile command on its own, that's only about 5 seconds. Without the verbose messaging, VS locks up for almost the entire compile process.

Turning off deep search includes increased compile time by a few seconds.

I guess I just have to accept that I'm working with a lot of code.

Yeah, u8g is the library for driving the display in this project. There are a TON of files that get compiled from that lib. The program would probably be closer to 60k if it weren't for the fonts used from u8g. Unfortunately, I'm using a lot of different sensors and components for this project, so keeping the size small is next to impossible.

Having gcc run in a separate thread will undoubtedly alleviate the hang of VS. Looks to me like the individual compilation operations, of which there are A LOT, are what are causing VS to hang.

Question: Is there anything I can do to speed up gcc compiling? It seems to me like the amount of time each operation takes is longer than I would expect. Some super small files take a couple hundred ms, and because there are so many of them (119 from u8g alone), they add up to that ~32 seconds.

You won't be able to speed up the compile that much. 

When is it an issue? Just changing between release/debug?

There has been a lot of dev work in cache and compile during the past few months so maybe you had an earlier version that behaved differently.

Thanks for the update. Please let me know if you find a combination that causes recompile when switching between release and debug.

No that's what I wanted to know thanks. It needs more intelligence and doesn't need to drop the lib and core cache when switching between Release/debug. It just needs to drop the local project sources cache and any local project libraries.

I suspect this changed when the new gdb debug option was released for the Arduino Zero. That allows core and libs to be debugged more easily but involves compiling with different optimization settings to the default. It's also possible to set different "defines -D" for different configurations such as "release/debug/custom" in the visual micro project properties. Again this would require a full recompile.

So what we need is to detect those two exceptions and only in that case drop the core/lib cache.

I'll add it to the list thanks.