Compilation speed of ESP8266 core 3.0.0

[sh-user]

Platform

• Hardware: [ESP-12]
• Core Version: [3.0.0]
• Development Env: [Arduino IDE]
• Operating System: [Windows]

Settings in IDE

• Module: [Generic ESP8266 Module]
• Flash Mode: [other]
• Flash Size: [4MB]
• lwip Variant: [v2 Higher Bandwidth]
• Reset Method: [ck]
• Flash Frequency: [40Mhz]
• CPU Frequency: [160MHz]
• Upload Using: [SERIAL]
• Upload Speed: [115200]

Problem Description

I compared the compilation speed
3.0.0 (gcc-xtensa v10.2) - first compilation 10 minutes, second compilation 10 minutes
2.7.4 (gcc-xtensa v4.8) - first compilation 5 minutes, second compilation less than 1 minute

[AcuarioCat]

I have the same problem.
Also, 3.0.0 breaks something - I'm investigating what it is but it takes time due to long compile times.

[fanfanlatulipe26]

Same problem.
In 2.7.4 first compilation/link 52s, second , third ... : 15s
In 3.0.0 : always arround 48s

Arduino IDE 1.8.13

[d-a-v]

Can someone working with windows and the git version confirm ? or infirm ?
Can someone working with Linux or macOS confirm ? or infirm ?

I am using linux and the git version without this issue. First compilattion lasts some times, the next one is around 10-15 secs.
I tried with linux on another user account and the standard installation procedure using the arduino IDE board manager also without issue (15secs the second time, using Arduino 1.8.14 hourly build 2021/04/08).

[Juppit]

On windows with arduino 1.8.13 I see this:
The second compilation with core 2.7.4 rebuilds no libraries (exept ESP8266WiFi, which is rebuild every time).
The second compilation with core 3.0.0 rebuilds all libraries.
So it needs nearly the same time like the first compilation.

You find it in c:/users/%user%/AppData/Local/Temp/arduino_build_xxxxxx/libraries

In my case I used this libraries:
ArduinoOta, ESP8266mDNS, ESP8266WebServer, ESP8266WiFi, SPI, Ticker, Wire

Hope this helps

[hreintke]

It's some time ago and I don't know whether it is related to this issue.

When I moved to the githead using the new compiler I had a similar issue.
I was related to the format of the ".d" files that the compiler generates to speed up compilation/search of related files.
That format has changed from old -> new compiler.
In combination with the make version I used on windows it was working OK or not.

I will search for the PR/issue where this is described and then edit this comment.
Edit : #6294 (comment)
Edit2 : I used make 4.3 from https://github.com/mbuilov/gnumake-windows to fix. (just a google search result, no other reason for choosing this one).

[fsommer1968]

@hreintke : How did you manage to use external make with arduino IDE?

[ElToberino]

Using the current release V 3.0.0 with Arduino IDE 1.8.13 on Windows 10 (20H2) I can confirm the compiling issue. The compiling process takes a longer time (quite noticable) than it did before with V 2.7.4 and the following compilings also do so.

Furthermore, loading files from SPIFFS (I know about depreaction) seems to be much(!) slower than it was before with V 2.7.4.

[hreintke]

@fsommer1968
I am not using Arduino IDE, I use Sloeber Eclipse development environment.
Don't know how make works in Arduino IDE but mentioned my experience as it might point to the root cause of the issue.

I do have Arduino IDE installed, so if I can be of help testing just let me know.

[d-a-v]

May I mention https://github.com/plerup/makeEspArduino

[earlephilhower]

Can someone please enable full logs in the IDE (File->Preferences->Show verbose output during, check compilation and upload boxes) and then do an initial compile, capture and post the logs, then do a minor change to the sketch.ino file and rebuild and capture the logs again?

For extra credit, if you could do the same w/2.7.4 which seems to run faster for you, that would be great. We would then be able to compare the commands run in 2.7.4 vs. 3.0.0 and see if a) there are more recompiles done, or b) the same number of gcc instances are run, but each one takes longer.

[sh-user]

Arduino IDE 1.8.13

First compilation 3.0.0.txt
Second compilation 3.0.0.txt

First compilation 2.7.4.txt
Second compilation 2.7.4.txt

[earlephilhower]

I'm on lunch so no time to dig super deep, but there does seem to be a dramatic difference in G++ calls between 2.7.4 and 3.0.0 on the 2nd round:

earle@server:~/Arduino/hardware/pico/rp2040$ grep g++ /home/earle/Desktop/First.compilation.3.0.0.txt | wc -l
631
earle@server:~/Arduino/hardware/pico/rp2040$ grep g++ /home/earle/Desktop/Second.compilation.3.0.0.txt | wc -l
555
earle@server:~/Arduino/hardware/pico/rp2040$ grep g++ /home/earle/Desktop/First.compilation.2.7.4.txt | wc -l
581
earle@server:~/Arduino/hardware/pico/rp2040$ grep g++ /home/earle/Desktop/Second.compilation.2.7.4.txt | wc -l
13

[earlephilhower]

Likely culprits would be something writing to the {build.dir} between runs causing a cache to be flushed/not used.

[earlephilhower]

I've been unable to repro this under Linux. @d-a-v or @devyte , have you seen it on your boxes.

Symptoms in the log are it's recompiling every library, every time, and not using the cached library.a file it built on the prior run.

So, my thinking is that this is a Windows-only thing and that @hreintke 's point about the .d file format change might be the core thing. I think it's always been technically illegal to have a make target with a : in it (that's the separator), but it seems the actual make code and gcc just read a %s and didn't really care what the filename was.

[JimDrewGH]

It's definitely recompiling every single library every time through (you can see that from the console output during the compile/linking), however, the more disturbing thing to me is that the compile time is 2 to 3 times longer than 2.7.4's first build. I could see maybe a few percent difference but not 200%+ of difference.

[d-a-v]

This is not reproducible on linux, but it is on windows.
As stated by @hreintke in #8069 (comment), the format of gcc-generated-depends file has changed, and gcc now writes in these files: C\:\Users\... instead of C:\Users\....
For a try, I made a random sketch build, then I changed all \: occurences to : from inside the .d files.
In the next build I got the message (using arduino-cli -debug-level 100):

===debug ||| Checking previous results for {0} (result = {1}, dep = {2}) ||| [C%3A%5CUsers%5CUSER%5CAppData%5CLocal%5CArduino15%5Cpackages%5Cesp8266%5Chardware%5Cesp8266%5C3.0.0%5Clibraries%5CESP8266WiFi%5Csrc%5CBearSSLHelpers.cpp C%3A%5CUsers%5CUSER%5CAppData%5CLocal%5CTemp%5Carduino_build_632486%5Clibraries%5CESP8266WiFi%5CBearSSLHelpers.cpp.o C%3A%5CUsers%5CUSER%5CAppData%5CLocal%5CTemp%5Carduino_build_632486%5Clibraries%5CESP8266WiFi%5CBearSSLHelpers.cpp.d]
===info ||| Using cached library dependencies for file: {0} ||| [C%3A%5CUsers%5CUSER%5CAppData%5CLocal%5CArduino15%5Cpackages%5Cesp8266%5Chardware%5Cesp8266%5C3.0.0%5Clibraries%5CESP8266WiFi%5Csrc%5CBearSSLHelpers.cpp]

(or)

===debug ||| Checking previous results for {0} (result = {1}, dep = {2}) ||| [C%3A%5CUsers%5CUSER%5CAppData%5CLocal%5CArduino15%5Cpackages%5Cesp8266%5Chardware%5Cesp8266%5C3.0.0%5Clibraries%5CESP8266WiFi%5Csrc%5CBearSSLHelpers.cpp C%3A%5CUsers%5CUSER%5CAppData%5CLocal%5CTemp%5Carduino_build_632486%5Clibraries%5CESP8266WiFi%5CBearSSLHelpers.cpp.o C%3A%5CUsers%5CUSER%5CAppData%5CLocal%5CTemp%5Carduino_build_632486%5Clibraries%5CESP8266WiFi%5CBearSSLHelpers.cpp.d]
===info ||| Using cached library dependencies for file: {0} ||| [C%3A%5CUsers%5CUSER%5CAppData%5CLocal%5CArduino15%5Cpackages%5Cesp8266%5Chardware%5Cesp8266%5C3.0.0%5Clibraries%5CESP8266WiFi%5Csrc%5CBearSSLHelpers.cpp]

And the build became very short in time, as before with windows, as now with linux.
(before the manual changes, messages were mentioning files like this: C%5C%3A%5CUsers%5C which is C\:\Users\)

That's not really on us, but on GCC changing file format, Arduino not yet interpreting the changes.
We could think of making a python script that'd change the .d files format but let's try to hear what Arduino thinks of this, considering that avr-gcc is also going to be able to use gcc10 in a short while.

[earlephilhower]

Looks like this is just a bug in the Arduino IDE, then. Good debugging, @d-a-v .

I see two possible solutions:

1. Wait for Arduino to fix it (but maybe they'll only do it in 2.0?)
2. Add a GCC patch to dump the : escaping (when a new -farduino flag is present if simple enough)

[d-a-v]

After a quick test using the alpha release 0.0.2 and windows10, this issue is fixed thanks to #8103.