Why is compilation so slow?

Dumb newbie question of the day: Why does it take so long to compile a simple program? My system might be a bit dated, but I've done a lot of C/C++ coding on a lot of MCUs over the years on this machine using quite a few compilers. I realize that in addition to my small test programs, a lot of library code needs to be brought in an linked. But considering my target is a Nano, which looks to have no more than 32K of flash, the compile process seems awful slow. Any solutions or alternatives?

The compilation time significantly increased in Arduino IDE 1.6.6 and newer when they switched to a new preprocessing system. They've done some work on improving it in recent versions but it's still an amazing difference when I do a test compilation on 1.6.5 or older. I think part of it is the process of scanning for dependencies. It used to be that you had to include any file that was included in any library you were using in your sketch but now you don't have to do that.

Some people also experience ridiculously slow compilation because their antivirus is doing a scan on each process/file during the compilation and there are a ton of them (and more since 1.6.6). You could check if that is a factor by TEMPORARILY disabling your antivirus for a single compilation to check the difference. Keep in mind that in recent IDE versions caching is done so the first compilation takes more time than subsequent compilations. This is reset when you switch boards. So be careful not to let that skew your tests.

Turn on "verbose" for compilation in the "preferences" panel, and you can look for any specific bottlenecks (although my experiences is that when it's slow for some reason, it just runs EVERY STEP particularly slowly.)

My last "this is slower than expected" experience went away as mysteriously as it had appeared, once W10 finished doing its updating/scanning/crap. Perhaps the compile processes started by Arduino are not recognized as "high priority user processes" and end up stuck behind other "maintenance" tasks. (Hmm. That's an interesting idea to chase down...)

I think you're definitely right about the priority. I've noticed that if I try to multitask by switching to the window of different application while the Arduino IDE is compiling it doesn't really progress at all until I switch back to the IDE window.

westfw:
Turn on "verbose" for compilation in the "preferences" panel, and you can look for any specific bottlenecks (although my experiences is that when it's slow for some reason, it just runs EVERY STEP particularly slowly.)

My last "this is slower than expected" experience went away as mysteriously as it had appeared, once W10 finished doing its updating/scanning/crap. Perhaps the compile processes started by Arduino are not recognized as "high priority user processes" and end up stuck behind other "maintenance" tasks. (Hmm. That's an interesting idea to chase down...)

Both Verbose checkboxes were off by default in my IDE, Arduino 1.8.3. I have no antivirus software except MalwareBytes, and its set to only scan at night (no real time scanning at all). I've other compilers on my system, one for Wixel boards, other CLI compilers with make files for various older intel and some motorolla boards. Nothing runs this slow for such a small project as "Blink". Hell, I have an ATARI ST emulator I've used to run motorola 68000 compilers, and they run circles around this.

I've been exploring an Eclipse plugin for working with arduous, but am not sure if it works with a faster open source compiler for the Amtel chips. I plan to try it for the programming convenience, but it functions as a layer over the existing Arduinno tools, it probably won't compile any faster. Maybe I'm just getting impatient in my old age. :slight_smile:

this slow

Care to attach some quantitative numbers to that? My rather ancient (but otherwise pretty zippy - ) Mac takes about 9 seconds to compile blink the first time. An old single-core Laptop running W10 takes between 10 and 20s. I'd say that anything under 30s is "not unexpected."

Both Verbose checkboxes were off by default in my IDE, Arduino 1.8.3.

Correct. Turn it on to see more about what is happening.

I realize that in addition to my small test programs, a lot of library code needs to be brought in an linked.

The Arduino core libraries are all compiled from source for each sketch, in order to better accommodate differing targets. So to build blink, the IDE actually compiles 25+ C and C++ programs. Plus it runs ar 25x to put most of them into a library.

I've been exploring an Eclipse plugin for working with arduous, but am not sure if it works with a faster open source compiler for the Amtel chips.

AFAIK, there's only one OSSW C/C++ compiler for AVR, so no matter which IDE you use you'll be using essentially the same core tools. Of course, other IDEs may make better use of parallelism and/or pre-building/etc... (for example, I'd THINK the ide could save some time by running ar with more than one .o file at a time... Significant time? Less clear. :frowning: )

I believe the core is now cached after the first compilation as long as you have File > Preferences > Aggressively cache compiled core checked. The IDE prints a message to the console that states the location of the archive when it is done on the first compilation.

pert:
I believe the core is now cached after the first compilation as long as you have File > Preferences > Aggressively cache compiled core checked. The IDE prints a message to the console that states the location of the archive when it is done on the first compilation.

Thanks. That option is indeed set. Eralier you asked "how slow"... my bad! :slight_smile: Takes about 30 seconds. To, that's a lot for BLINK, at least being used to other C compilers and situations where everything not in my project source is already compiled (but just not linked) in libraries. If this system works by having to gather and actually re-compile every bit of support code, I guess this timing makes more sense. Still, considering the total flash space in my MINI, its hard to believe that even on my old Win-XP system system anything should take that long. Its still 3.2Ghz and a 4 core intel CPU. I can live with it. But if there's an obvious fix r alternative, it would be fun to try.

Yeah i figured using eclipse would just make to coding easier, unless there's a better open source compiler on the way.

I am suspicious of the system installing all its libraries and resources completely in "Program Files" under Windows, all in "Read only" files. I'd think a better install would have put everything into "Application Data" or another user space. I guess I could make a backup copy of the whole install tree, and change the permissions on the original to "Read/Write/Modify", just to see if it speeds up over time.

I remember one user reporting they had tracked down the cause of a slow compilation to some of the files being located on a network drive. Maybe it was their temporary build folder, I can't remember the exact details.

Its having contention with the anti-virus software.

I'm having the same problem since I started to use the "nano 33 BLE Sense". Compiling "Blink" was a matter of very few seconds for the "nano every", but takes at least 30 seconds for the BLE Sense.

The first compile of "Blink" even took several minutes and put all 4 cores of my Win7 PC to maximum load during most of that time.

The most annoying part is, when you first pressed "compile" only and then want to upload the sketch, the IDE again starts to compile, although nothing has changed. The underlying "make" process doesn't seem to be very efficient.

This is especially annoying, as the BLE Sense uses 2 COM ports: one for the Bootloader and one for the serial port (e.g. Serial Monitor). If you forgot to double-click the reset button and set the right port before trying to compile & upload, you will have to compile again, as an "upload only" option is not available in the IDE and the COM port keeps changing away from the Bootloader after the sketch has been uploaded.

Disabling the Antivirus Tool definitely makes compile times a lot shorter.

The compilation time for Nano 33 BLE will always take longer than for the other boards, though there are some things you can do to speed it up, as you discovered. The issue is that, unlike any of the other boards before it, the Nano 33 BLE uses Mbed OS, which provides some nice functionality, but is also huge.