arduino slow compilation caused by GCC?

[kurtow187]

Dear community,

after some month of pausing, I returned to programming Bluepill with official Stmduino-core.

I updated to Arduino IDE 1.8.16 and Core 2.1.0

My 'old' sketch (medium complexity) now needs 56 seconds for compiling
(with IDE 1.8.10 and Core 1.9 it needs only 10 sec to compile)

I tested some other IDE's... with this results

Arduino IDE 1.8.16 56 sec
Arduino IDE 2.0 beta 12 59 sec
VsCode (with arduino extension) 72 sec

I think the reason for the long compile time is, that everything is always recompiled.


Somewhat disappointed, I decided to uninstall all my IDE's
and return to my Arduino IDE 1.8.10 (portable) with Core 1.9

But since I had nothing to lose, I took the
latest G-C compiler from homepage and simply copied the new files over the version in core 2.1.0 directory.

(Files from gcc-arm-none-eabi-10.3-2021.10-win32.zip (from 21. October 2021) over the files in my folder 10.2.1-1.1)

Surprisingly, everything then worked perfectly!!
the new compile times with 2.1.0 now are

Arduino IDE 1.8.16 10 sec
Arduino IDE 2.0 beta 12 19 sec
VsCode (with arduino extension) 16 sec

Maybe this tip can be helpful for some one...
(But please be careful !! I am only a newbie and amateur with rudimentary knowledge)


regards

kurtow187

[mrburnette]

kurtow187:

Interesting. However I have multiple IDE installations on Win10 and "no issues noticed." Same (as one would expect) with Linux. Such "extended" compile/link times may be nothing more than Windows "constipation." The Arduino IDE is JAVA-based and each IDE-version installs its own copy and this can lead to strange happenings with the classpath as well as the binaries for GCC which are "shelled" by the IDE.

I have not looked into Arduino installation differences between Zip install vs Windows installer, but typically Windows Installer will utilize the registry to (as a minimum) keep state information for uninstallation. The registry with Arduino as I remember is not heavily utilized; but Version 2 could change that... something I need to investigate.

As I stated this is interesting, but a better test would have been to use an identical makefile to do a CLI compile/link and timed those events.

I would strongly suggest not upgrading the GCC components by over-writing files; old artifacts can reside in the file structure (different file names, flat files used for tuning and versioning, etc.) At best, overwriting leaves one with a potentially "unclean" installation.


Ray

[kurtow187]

mrburnette:

Thank you for information!

I would strongly suggest not upgrading the GCC components by over-writing files; old artifacts can reside in the file structure (different file names, flat files used for tuning and versioning, etc.) At best, overwriting leaves one with a potentially "unclean" installation.

I see it exactly the same way!

[ag123]

there may be a way to speed things up, which is to use CMake
https://cmake.org/
but this redesign would break compatibility with Arduino IDE.
And actually newbies will have a hard time trying to use cmake, as you would need to define your cmakelist.txt manually with hardly any instructions at all.
The idea is to inject the dependencies that you use, i.e. dependency injection, by specifying them in the cmakelist.txt file.
Then cmake generates a makefile that does the build.
This stuff is very non-Arduino-ish, some newbies are scared of this, but Raspberry Pico SDK does it that way exactly.
serial is *injected* and not a class, so it can be swapped for usb-serial, uart-serial, and some arbitary serial that has a similarly templated api.

Another thing is c++ templates, which can probably be explored at some point in time. it has some features close to dependency injection, but isn't the same.

Those 'one liner cmakelist.txt' will also massively confuse any 'beginners' as it simply specify a set of dependencies.
-------
In the meantime a way around it is to fix the temporary build folder that can be set in the IDE config file.
This is so that it won't need to rebuild all the object files with each change.

[mrburnette]

...
In the meantime a way around it is to fix the temporary build folder that can be set in the IDE config file.
This is so that it won't need to rebuild all the object files with each change.

For 10 years I have used the "slow" excuse as the primary reason to upgrade my notebook and I am not going to mess around with what my wife has now accepted to be an annual requirement.

Seriously, changing out a spinner harddisk for SSD will decrease compile+link time. But I cannot imagine that anyone can justify spending i7/i9 level of money for a new PC just because of decreased wait time! During uni I had to code Fortran on paper, punch cards, submit my card deck, and wait for a batch run of the code. Sometimes, output came hours later or next day. Today's iterative coding mentality, say change a cursor.locate() by one position and then recompile is absurd; buy a pad of graph paper and think through the problem.

But, if the PC hardware is too old, enhancements like SSD's may not be worthwhile. I have not purchased a new PC/notebook since retiring 12 years ago. Grade "A" refurbished hardware is just too plentiful and is priced significantly below new prices. Some refurbishes supply MS Windows Pro free and even offer a 1-year replacement warranty and free shipping.
Google: https://www.google.com/search?q=best+pc ... fubrishers

Just remember, COVID has caused "at home hardware" to put pressure on refurbished stock of "A" units, so prices are inflated.

Ray

[DirkU]

Ran into exactly the same issue like kurtow187

After upgrading stm32 core from 2.0.0 to 2.1.0 on Arduino 1.8.16 caching for core and libraries did not work anymore, each re-build w/o touching the sketch took more than a minute... Reinstalling Arduino 1.8.16 using the Windows 10 installer didn't help, same non-caching behavior. Downgrading to Arduino 1.8.15 didn't help either , same non-caching behavior.

But downgrading stm32 core to 2.0.0 was a success! Caching worked again, lots of "Using cached library dependencies for file:" messages and re-compile times were down to the usual 10sec or so. Re-upgraded to 2.1.0 and again... no more caching, recompiles of unchanged sketches were back to 60s+. When compiling for ESP32 or AVR chips caching worked always with 1.8.15 as well es 1.8.16.

So there is definitely a dependency of the "recompile-everything-every-time" behavior and the new 2.1.0 core version

Cheers,
Dirk

[fpiSTM]

Well the main difference is the gcc used.
2.1.0 uses this one: https://github.com/xpack-dev-tools/arm- ... 10.2.1-1.1

A new version has been released based on October 2021 release:
https://github.com/xpack-dev-tools/arm- ... 10.3.1-2.1