Please point me at instructions for speeding up the Due beta compiler.

I am developing projects on an Arduino Due using the beta compiler called arduino-1.5.6-r2 , and I have also used a recent "nightly build toolchain" compiler mentioned on the development list.

Both compiler configurations take a long time because they seem to compile everything and then download and verify stuff.

Most of this compiler activity is controlled by a file called .arduino15/preferences.txt

So I ask, where could I find instructions for safely speeding up the compile cycle by editing preferences.txt?

My current project is to integrate a AZ-000` CO2 meter with a gps and a barometer and a SD card real time clock. Putting all these things together is basically a lot of plinking. The CO2 meter has a rather problematic serial interface that requires so far a lot of trials.

Thanks for a reply and hang on out there! Lee

I have a copy of the Arduino Uno development environment, where compiles are quite brisk.
I tried copying "preferences.txt" from the speedy Uno development environment over to the .arduino15/perferences.txt file.

I was disappointed. after changing the preferences file, a typical compile of a recent program source file did not show more speed.
The compile cycle for the Due still seems to recompile everything, and then spend more time uploading and verifying.

So, the simpleton's speed up did not work.

Are you finding compilation is the critical step? I find the download and verify
the slowest part by a large margin for small sketches - compile takes longer than
for ATmega based boards due to the larger libraries for SAM3X

Arduino software compiles everything from scratch each time to avoid any problems
of mismatch between source to object files, which is probably a good thing.

Slow is a relative term, compiles always seem quite quick to me, but then I am used to large systems where builds can take a while. Anything less than 1-2 minute is quick enough for me.

I don't think there is a way to speed up the IDE. Due to the way the IDE works, it has limited support for incremental builds. Ideally it would use a "make" type system and only build what has changed. I think it would take some work to change the IDE.

You could try Eclipse with the Arduino plugin, Eclipse uses make files to build.

Apart from that, a faster PC.

Perhaps your machine is thrashing? How much RAM does it have?

[ I get about 5 seconds to compile small sketches ]

Sadly, it seems the patch I contributed to Arduino years ago, to only recompile files that have actually changed, has somehow been lost in 1.5.7. This has recently been reported as a bug, so hopefully it'll get fixed in 1.5.8 or 1.5.9?

The known bug where a space isn't recognized in the pathname is my fault. I mostly use Linux, and then I port to Mac, and I always do Windows last, because it's the most painful. When I tested on Windows, I used "c:\arduino", mostly because that makes things simpler to copy files over from my Linux machine, so I didn't notice the bug with not properly handling spaces.

I fixed this some time ago in Teensyduino, but sadly my code has drifted pretty far from Arduino's version, and they're in deep maintainence mode on the 1.0.x branch now, so odds are slim my fix will ever get into the 1.0.x branch. It's also a good question whether they'll ever release 1.0.6....

Due's slow upload speed is mostly caused by bugs in Atmel's bootloader. The bootloader is permanently burned into the mask rom inside the chip, so it can be updated. Atmel is unlikely to ever fix those bugs, due to the high cost of revising the silicon. Their own FLIP programmer apparently uses the buggy bootloader to upload a faster one to RAM, which it then runs and uses to upload code quickly. Of course, Atmel never published any of that code, so Arduino can't use it. It seems unlikely anyone will ever go to the trouble of developing something like that for Arduino Due.

Edit: I have put a lot of work into optimizing upload speed on Teensy 3.1. If you'd like to see how fast upload can be, give it a try. I believe on most computers, where there's significant USB bandwidth available (eg, not all used up by webcams or USB hard drives), it's limited in speed only by the USB enumeration time to detect the reboot, and the actual flash write throughput on the chip.

You don't mean that? Files need recompiling when any file they depend on changes, or
the board selected changes, etc etc.

MarkT:
You don't mean that?

Yes, you're right, I oversimplified in that quick comment.

Files need recompiling when any file they depend on changes, or
the board selected changes, etc etc.

Yes, of course it does that, using the .d dependency files created by previous runs of the compiler.

I've published this patch for several years in Teensyduino and Arduino has published in since version 1.0.1. It's worked very well all this time.

All the source is available, if you're concerned about the implementation.