I'm using Arduino IDE 2.3 on a MacBook Pro laptop 2.3 Ghz Quad Core Intel I7 on Sonoma 14.4.1. My Reflections project has 1 .ino file and 25 .cpp files. It's about 15,000 lines of code in total. Code is here: GitHub - frankcohen/ReflectionsOS: Reflections is a hardware and software platform for building entertaining mobile experiences.. It takes about 8 minutes to compile the code. During the compile the aggregate CPU is 11% used. It seems the compiler is using 1 of the cores only. What ways are there to compile the code in less than minute? -Frank
Check the compiler logs. How many of the .cpp files are being compiled every time? A .cpp file should only get compiled if it or a header files that it #include(s) has been changed since the last build.
how long does it take to re-compile the code after a change?
because the IDE supports the same code on many other processors, the source for libraries needs to be compiled. but isn't compiled when you modify your code without closing the IDE. the compiled libraries are sitting in the sketch director
Takes about 4-5 minutes to rebuild. Same 10% CPU usage. Feels like there is a lot of upside.
Load a Linux demo and see what the difference is. I expect it will be a lot faster.
1 Like
Also have a look here: performance - Why does C++ compilation take so long? - Stack Overflow
Although it may not be your main problem here I did notice that, for example in Accelerometer.h, you are repeating the #includes in Accelerometer.cpp. There may be a reason for this but in general it is better to limit what is in the .h file to that which is required elsewhere to use the interface.
The complaint is not new 
Excessive time for simple build has some more information (but not a definite solution).
Hmm. I raised a ticket on this a couple of weeks ago and was told "Although some users have reported complaints to us about this, the cases are minimal".
Compiling will use available cores, but "Detecting Libraries" does not. In File | Preferences, you can turn on "Show verbose output during: compile" to follow along. I wrote a small patch to add basic timing to arduino-cli, the back-end for IDE 2.x. I pulled your repo and after adding some blank secrets and a missing #include in the .ino, I got this timing on a quad-core
prepare 0.718
detecting libraries 103.323
function prototypes 1.030
compiling sketch 6.413
compiling libraries 63.048
compiling core 5.079
linking 9.368
final 0.795
--------
Total 189.773
Immediate rebuild takes the times way down
prepare 0.784
detecting libraries 15.963
function prototypes 1.089
compiling sketch 1.348
compiling libraries 1.085
compiling core 0.206
linking 6.730
final 0.732
--------
Total 27.938
but Detecting Libraries, while taking advantage of cache, still makes it "not instant". (And linking too.) BTW, adding --jobs 1 to disable multi-threading increases the clean build time to
prepare 0.697
detecting libraries 103.188
function prototypes 1.023
compiling sketch 14.922
compiling libraries 125.508
compiling core 10.653
linking 9.396
final 0.774
--------
Total 266.161
The compile times are roughly double.
You use... 26 libraries, which I would guess is above average.
Hi, this is my observation as well even though parallel build is supposed to engage by default.
If you use libraries try to precompile them into .a. That helped a lot with my build times.
1 Like
Could not ninja be used as Arduino IDE build system ?
I was using Keil uVision over last 3y and with every new IDE revision, build times seemed to get slower and slower.
Out of frustration, I tried ninja to build my project (~200 .cpp and ~60 .c) and I could not believe the speed of that build system. Shocking.
When trying to improve build times with Keil support, I learnt they are porting their ecosystem to ninja.
1 Like
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.