Forum: Compiler & IDEs Arduino IDE 2.3.2 was dauert so lange ?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Bjoern B. (per)


Lesenswert?

Moin,
ich hab ein relative grosses Arduino RP2040 Projekt, mit ner compilezeit 
von ca. 15 sec. getestet auf verschiedenen aehnlichen Rechner.
Was dauert da so lange 150kb Programm zu erzeugen.
Da das Projekt viel try and error ist, was wie könnte man beschleunigen 
?
wie sieht das auf nem modernen Rechner aus ?

gruss,
Björn

von Gerhard O. (gerhard_)


Lesenswert?

Bjoern B. schrieb:
> Moin,
> ich hab ein relative grosses Arduino RP2040 Projekt, mit ner compilezeit
> von ca. 15 sec. getestet auf verschiedenen aehnlichen Rechner.
> Was dauert da so lange 150kb Programm zu erzeugen.
> Da das Projekt viel try and error ist, was wie könnte man beschleunigen
> ?
> wie sieht das auf nem modernen Rechner aus ?
>
> gruss,
> Björn


Moin,

Mir ist aufgefallen, daß Arduino Kompilieren unter Mint Linux in meiner 
VM Umgebung mindestens fünf mal schneller als im Host W10X64 System 
abläuft. W10 braucht da deutlich mehr Zeit. Allerdings spreche ich hier 
nur von AVR GCC. Wie das beim RP2040 ist, kann ich nicht beurteilen.

Vielleicht unternehme etwas Ähnliches. Virtual Machine Player ist frei 
für Non-Commercial Use und Mint lässt sich dort leicht installieren. 
Dann kannst Du ja den Unterschied messen.

Dann kannst Du zum Kompilieren einfach, wenn nötig, schnell auf Linux 
umschalten, wenn Mint bei Nichtgebrauch im Dornröschenschlaf (Suspend 
Mode) verbleibt. Das Hochfahren dauert nur ein paar Sekunden.

Gerhard

: Bearbeitet durch User
von J. S. (jojos)


Lesenswert?

Auch im WSL geht der Build viel schneller. Es ist aber nicht nur das 
reine Kompilieren, der Linker braucht auch Zeit, es wird ja ein großer 
Brocken vom Core dazugelinkt.
Mit WSL geht das mittlerweile sehr gut, ohne eine VM installieren zu 
müssen. USB ist etwas fummelig, geht mit usbipd aber auch sehr gut, vor 
allem mit aktueller Version 4.0.

von Εrnst B. (ernst)


Lesenswert?

Keine Ahnung ob das immer noch ein Problem ist, aber früher zumindest 
war da oft der Virenscanner schuld. Beim Compilieren werden haufenweise 
Source-files/includes gelesen und auch viele temporäre Objekt-Dateien 
angelegt, die alle einen OnAccess-Scan anstoßen.
Abschalten, testen, falls es dann besser ist: Schauen wie man eine 
Ausnahmeregel für die Arduino-Ordner festlegen kann.

von Bjoern B. (per)


Lesenswert?

das Arduino compilieren unter Linux wesentlich schneller ist, ist 
intressant
da werde ich mal versuche machen

gruss,
Björn

von Bjoern B. (per)


Lesenswert?

Virenkiller abschalten, bringt nicht wirklich was
bereits getestet

von Bjoern B. (per)


Lesenswert?

Ich hab mal ein Mint auf einen der Rechner installiert, 5-10mal so 
schnell beim compilen.
gut zu wissen,
dann  kann man weiter forschen.

gruss,
Björn

von Harald K. (kirnbichler)


Lesenswert?

Ich habe mehrfach beobachtet, daß der Compiler in der Arduino-Umgebung 
viel schneller ist als die Ausgabe im Arduino-Fenster.

Das kann man leicht nachvollziehen: Übersetzen und gleich aufs Target 
laden lassen. Das Target fängt schon mit dem neuen Programm an zu 
blinken, währenddem durch das Ausgabefenster noch der Text des Compilers 
kriecht.

Und das habe ich auch bei Projekten nahezu trivialer Größe beobachtet 
(win10x64 auf hinreichend leistungsfähigem PC ohne Schlangenöl).

von Μαtthias W. (matthias) Benutzerseite


Lesenswert?

Hinter der Arduino-IDE steckt ja ein GCC. Und der ist unter Windows auf 
dem gleichen Rechner erheblich langsamer als unter Linux. Warum das so 
ist erschließt sich mir aber auch nicht. Auf meinem Testsystem war 
damals "nur" der Windows Defender aktiv.

Matthias

von Mi N. (msx)


Lesenswert?

Harald K. schrieb:
> Das kann man leicht nachvollziehen: Übersetzen und gleich aufs Target
> laden lassen. Das Target fängt schon mit dem neuen Programm an zu
> blinken, währenddem durch das Ausgabefenster noch der Text des Compilers
> kriecht.

Das ist mir auch aufgefallen.
V 2.3.2 ist zwar deutlich schneller geworden als die 1.x, es dauert aber 
trotzdem seine Zeit. Für 80 KB braucht mein WIN10 PC ca. 4 s.
Testweise werde ich mal den Virenscanner abschalten.

Bjoern B. schrieb:
> Ich hab mal ein Mint auf einen der Rechner installiert, 5-10mal so
> schnell beim compilen.

Aber deshalb gleich das Betriebssystem zu wechseln?
Trinke mehr Tee, da brauchst Du eh noch zusätzlich Pausen zur Entsorgung 
;-)

von Jim M. (turboj)


Lesenswert?

Wenn da -flto in den Compiler Optionen an ist, nimm das mal raus.

Linkt Time Optimization ist ziemlich teuer - denn da wird das Projekt 
nochmal fast vollständig compiliert. Reines Linken ist dagegen eher 
preiswert.

Auf modernen Kisten kannste den C-Compiler stärker parallel laufen 
lassen - den Linker aber eher nicht.

Windows braucht vergleichsweise ewig für einen Programmstart, und bei C 
wird für jede Datei (.c, .cpp) der Compiler einmal aufgerufen.

: Bearbeitet durch User
von Mi N. (msx)


Lesenswert?

Jim M. schrieb:
> Wenn da -flto in den Compiler Optionen an ist, nimm das mal raus.

Verrate mal, wie das geht.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Bjoern B. schrieb:
>  wie könnte man beschleunigen ?

Mit -O0 -g0 compilieren.  Optimieren kostet eben Zeit, und -O0 optmiert 
auf Host-Resourcen.

von Michael S. (the_mole)


Lesenswert?

Die lange Compile-time der Arduino IDE ist mit ein Grund warum ich 
lieber mit PICs als AVRs arbeite.
Es geht einfach viel schneller.

Das Compilieren von Marlin (3D-Drucker Betriebssystem am Arduino Mega) 
nimmt mal gerne >5 Minuten in Anspruch...

Selbst mein neuer Laptop, ein HP Pavilion mit Ryzen 5 konnte das nicht 
maßgeblich verbessern, ich weiß nicht woran es liegt.

Der CCS C-Compiler (Microchip) braucht selbst bei sehr großen Programmen 
selten länger als 5s, erstellt aber sicher 8-10 Files in der Zeit. Beim 
Klick auf den Build-Button ist das Programm schon quasi auf dem 
Controller.
Wenn ich dort auch so lange warten müsste wie bei der Arduino IDE, ich 
hätte das Hobby vor 10 Jahren aufgegeben...

: Bearbeitet durch User
von Harald K. (kirnbichler)


Lesenswert?

Michael S. schrieb:
> Die lange Compile-time der Arduino IDE ist mit ein Grund warum ich
> lieber mit PICs als AVRs arbeite.

Was'n das fürn beklopptes Argument? Als ob man AVRs zwingend mit der 
Arduino-IDE programmieren müsste.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Johann L. schrieb:
> Bjoern B. schrieb:
>>  wie könnte man beschleunigen ?
>
> Mit -O0 -g0 compilieren.  Optimieren kostet eben Zeit, und -O0 optmiert
> auf Host-Resourcen.

Hier mal ein konkretes Beispiel: Compilieren der vfptintf_flt.o aus der 
AVR-LibC mit avr-gcc-v14:

-O3: 1.30s
-O2: 1.15s
-Os: 0.75s
-O1: 0.45s
-Og: 0.25s
-O0: 0.15s

Das übliche -Os braucht also die 6-fache Zeit wie -O0.

Spielt man noch an der Debug-Info rum (-g0 statt -g3) dann wird's 
nochmal 15% schneller.

Das ist jetzt nur die Zeit um ein Modul ohne LTO zu compilieren.  Mit 
LTO gehen die Compile-Zeiten dann massiv runter, dafür geht die 
Link-Zeit (was ja die Zeit für LTO-Bytecode Compile enthält) durch die 
Decke.

Oben wurde ja schon emfohlen, LTO rauszunehmen.

von Oliver S. (oliverso)


Lesenswert?

Johann L. schrieb:
> Das übliche -Os braucht also die 6-fache Zeit wie -O0.

Ja, und?

Oliver

von Oliver S. (oliverso)


Lesenswert?

Michael S. schrieb:
> Das Compilieren von Marlin (3D-Drucker Betriebssystem am Arduino Mega)
> nimmt mal gerne >5 Minuten in Anspruch...

Ja, das ist natürlich völlig inakzeptabel. Wenn man 20 mal täglich das 
Betriebssystem komplett neu kompilieren muß, behindert das den workflow 
doch ganz beträchtlich.

Das der gcc unter Windows deutlich langsamer agiert als unter Linux, 
auch und gerade bei solchen Winzprogramme, die auf einen AVR passen, ist 
altbekannt.
gcc arbeitet beim Compilieren halt mit unzähligen Dateien, und dieses 
Dateihandling ist bei Windows nicht sonderlich effizient.

Oliver

von Veit D. (devil-elec)


Lesenswert?

Mi N. schrieb:
> Jim M. schrieb:
>> Wenn da -flto in den Compiler Optionen an ist, nimm das mal raus.
>
> Verrate mal, wie das geht.

Hallo Micha,

wenn die IDE installiert ist, liegen Dateien unter
... AppData\local\Arduino15\packages\arduino\hardware\avr\1.8.6

Je nach installierten Core Package weicht der Pfad am Ende ab.

Die entscheidende Datei ist hier platform.txt für das jeweilige Core 
Package.
Im einfachsten Fall nimmt man hier für C++11 die Option -flto raus

oder lässt diese Datei in Ruhe und legt Änderungen in einer 
platform.local.txt an. 
https://arduino.github.io/arduino-cli/0.25/platform-specification/#global-platformtxt

https://arduino.github.io/arduino-cli/0.25/platform-specification/#platformtxt

https://arduino.github.io/arduino-cli/0.25/platform-specification/#platformlocaltxt

: Bearbeitet durch User
von Mi N. (msx)


Lesenswert?

Hallo Veit,

vielen Dank für die Links! Da habe ich zumindest schon mal einen Ansatz, 
wo die Schrauben zum Drehen sind. Die Arduino-IDE für den 'Normalnutzer' 
ist ja doch recht beschränkt.

Da ich mit dem RP2040 spiele, hat ein Update auf Version 2.3.0 schon 
eine deutliche Beschleunigung gebracht. Hinzu kommt bei dem Controller, 
daß immer noch der USB-Stack dazugepackt wird, sodaß selbst ganz 
einfache Programme rund 60 kB groß werden. Das Kompilieren dauert dann 
rund 4 s, sodaß man recht schnell (Fehler)-meldungen bekommt. Mal sehen, 
ob sich da noch etwas beschleunigen läßt.
Da ich in der Regel fertige Programmmodule auf Arduino portiere, muß ich 
nicht jedes Detail neu überprüfen.

Beim AVR sind die Programme deutlich kleiner und ob da das Kompilieren 
nun 0,15 s oder 1,3 s dauert, wäre mir egal. Eine Maschine, die immer zu 
schnell reagiert, kann auch Stress machen. Es muß immer noch Zeit 
bleiben, in der man sich durch den Kopf gehen läßt, was man da gerade 
gemacht hat.

Eben mal probiert:
Beim RP2040 ist kein -flto zu finden. Die Optimierung steht auf -Os und 
eine Änderung auf -O0 reduziert die Übersetzungszeit unmerklich 
(Kopftimer). Vielleicht müßten alle Projektdateien neu kompiliert 
werden, um einen deutlichen Unterscheid zu spüren.

: Bearbeitet durch User
von Steve van de Grens (roehrmond)


Lesenswert?

Bei AVR funktioniert die delay Routine der Standard Bibliothek nicht 
richtig, wenn man den Optimizer mitteln -O0 ganz deaktiviert. Es kann 
auch passieren, dass zeitkritische Registerzugriffe (die direkt 
nacheinander stattfinden müssen) nicht mehr funktionieren - es sei denn, 
man implementiert sie in Assembler.

-O0 ist daher bei mir quasi verboten.

: Bearbeitet durch User
von Oliver S. (oliverso)


Lesenswert?

Steve van de Grens schrieb:
> Es kann
> auch passieren, dass zeitkritische Registerzugriffe (die direkt
> nacheinander stattfinden müssen) nicht mehr funktionieren - es sei denn,
> man implementiert sie in Assembler.

Daher gibt es dafür in der avrlibc passende Makros, die genau das für 
einen erledigen.

Oliver

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.