I need someone to modify how Arduino IDE 2's C/C++ compiler builds projects to take advantage of my Macbook Air M2 2022 8 cores to speed-up compile time. I have a $1000 budget and will open-source the work for all to benefit. -Frank
read some information about the CLI and library detection
- The
Detecting libraries used...phase. This is the slowest. It's also not easy to fully cache and/or parallelize, because it actually requires runninggcc -Eon the sketch to check if there are missing includes (the installed libraries may have changed in the meantime). The same process must be done on all the compilation units in the included libraries: this may become very long if there are hundreds of files.
@fcohen ,
I've moved this to the paid jobs part of the forum as that seems more appropriate.
Perhaps you can clarify here, because the PR is essentially already done I believe, see Improved compile speed by running multi-threaded library discovery. by cmaglie · Pull Request #2625 · arduino/arduino-cli · GitHub. So that is in the pipeline for an eventual official IDE release (hopefully).
I guess in the meantime someone could provide you with an unofficial IDE build with this PR to use.
Awesome. I didn't see PR 2625. Thanks for pointing it out. Now I'm wondering what they did... A lot of compilers, internally, are usually single core and I'm wondering if there are options to speed up linking? -Frank
Thank you.
The PR looks interesting. I offered to spend time and money testing it. It's a bit experimental right now.
For my immediate needs I would be fine with a build script I run external to Arduino IDE 2 that does a faster compile and upload. I'm using Arduino IDE 2.x everyday on my open-source ReflectionsOS project (see ReflectionsOS on Github). It's an ESP32-S3 board with a bunch of sensors. About 18,000 lines of code so far. Compiles on my MacBook Air M2 2022 8 Cores takes about 3-4 minutes. I would be fine with a utility I could call from the Terminal/Command Line to build and eTool deploy to the board.
-Frank
The compiler is usually single-threaded, but since most builds involve many files, you can usually speed things up substantially by simply compiling multiple files in separate jobs. "make -j" does this in more conventional environments. But Arduino doesn't use "make."
My interpretation is that that an Arduino does the equivalent of "make depend" AND "make" for each build, and it's the dependencies calculation that is both slow and more difficult to parallelize.
takes about 3-4 minutes.
"Oh, the horror. Sigh. Kids today!"
LOL
I remember when, not so long ago, I would hit "Build" and get up and have a cup of coffee or two before our entire C++ project finished. I think a full clean & build took around 35 minutes.
These days, if it's not over in a minute I wonder if something's broken.
1 Like
arduino-cli has a --jobs flag, defaulting to "number of cores" as seen by its Go code, used when compiling. I have a patch that prints timings for the eight build stages. On a Mac with 4 Efficiency cores and 8 Performance cores, with a moderately complex ESP32 sketch
| --jobs 1 | --jobs 2 | --jobs 4 | --jobs 8 | --jobs 12 | |
|---|---|---|---|---|---|
| prepare | 5.423 | 5.439 | 5.258 | 5.551 | 5.325 |
| detecting libraries | 17.543 | 17.772 | 17.574 | 17.567 | 17.377 |
| function prototypes | 0.398 | 0.420 | 0.399 | 0.397 | 0.376 |
| compiling sketch | 3.470 | 2.522 | 2.143 | 2.284 | 2.365 |
| compiling libraries | 19.548 | 11.589 | 8.589 | 7.945 | 9.039 |
| compiling core | 4.705 | 2.958 | 2.472 | 2.451 | 2.708 |
| linking | 2.164 | 2.138 | 2.083 | 2.100 | 2.124 |
| final | 5.298 | 5.439 | 5.444 | 5.430 | 5.429 |
| -------- | |||||
| Total | 58.550 | 48.276 | 43.962 | 43.724 | 44.743 |
This is a single run for each, so take those numbers with a fistful of salt
- 12 is not faster than 8
- with the Activity Monitor's CPU History window, it appears that 8 pins all the Performance cores, while not using the Efficiency ones, which is what you want
- 2 does not double the speed (expected), but 8 is not much better than double, and only for libraries
"prepare" and "final" are what happens at the beginning and end, surrounding the formally announced parts. On Mac (this one at least), it's five seconds each for ESP32. For Uno, it's about 0.25 seconds each. This appears to be related to the built-in anti-malware, system integrity stuff, with esptool.py or whatever being scrutinized. On Linux, ESP32 is also some fraction of a second. On Windows, it's a few seconds each; faster with a Dev Drive.
PR 2625 improves the "detecting libraries" stage, where you can expect the time to be cut in about half.
That should be the easy part, and unnecessary. As long as you patch the version of the CLI that matches the IDE, e.g.
then after building arduino-cli (pretty easy), you just replace the bundled one -- after making a backup first. On a Mac, it's
$ find /Applications -name arduino-cli
/Applications/Arduino IDE.app/Contents/Resources/app/lib/backend/resources/arduino-cli
If you want to give that a try, here's my benchmarking patch, so you can see your potential gains. Beats using a stopwatch. The name says 1.0.3, but works for 1.0.4, and maybe for 1.1.1
bench_1.0.3.patch.zip (1.6 KB)
$ git apply ~/Downloads/bench_1.0.3.patch
$ task build
1 Like
The last place I worked, a full build or “make depend” (both of which one tried desperately to avoid) took about 4 to 6 hours… (running on a big Sun build farm, but I think, pre-ssd.)
ouch!
I remember a time (working on Multics at the time) when we were carefully proofreading our source code because compilation jobs were run during the night and we needed to await the next morning to see the result of the job you had submitted in the queue…
You did not want to see the « missing semicolon in line 3 » error message as a result…(and it would eat up also your compute time credit).
1 Like
me too 
There's a lot to be said for modern tools that warn you of problems before you even begin to compile.
looking at the numbers I would say that 8 is not even faster than 4.
Most gain is seen at the compilation of the libraries.
Normally a recompile would not be needed (for same project).
@fcohen
What might be interesting to look at is this line
It might be that you have many libraries installed that are not used.
If you - temporary - remove those not used and only have the mandatory ones in your library folder, it might take less time to detect them.
- rename the existing library folder to library.all
- make a new library folder
- copy the needed ones into it.
Could you give it a try?
What about memory usage / swap ?
I suspect that there is a lot of room in the ESP32 world to pre-compile a bunch of the libraries, probably at the expense of easily dealing with so many different CPU and board types within the same "core."
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.