Avatar von fschutt
  • fschutt

13 Beiträge seit 26.09.2017

Re: Inkrementelles Bauen

In gewisser Weise hast du recht, es ist mehr ein "aufholen", aber mit ein paar Unterschieden.

Rust hat ein etwas anderes Kompiliermodell als andere Sprachen: In C ist eine Quelldatei = eine Objektdatei. Das Linking geschieht über Header-Dateien. Rust hat keine Header-Dateien. Wie man im Bild im Artikel gut sieht, kann eine Änderung im Quellcode mehrere Objekt-Dateien betreffen. Wenn du also einen Typ änderst, muss Rust "herausfinden", welche anderen Typen / Dateien davon abhängen, ob die generischen Typen verändert wurden, inwiefern das Borrow-checking betroffen ist, etc. Und das kann dauern.

Zusätzlich kann man in C diese Sachen einfach parallelisieren, indem man jede Quelldatei in parallel in eine Objektdatei übersetzt. Rust macht hierbei aber aggressive Funktions- und Modul-übergreifende Optimierungen, dafür muss der Rust-Compiler aber "wissen", dass andere Module vom Optimierer nicht mehr angefasst werden, da sonst die Integrität des Programms ja verloren geht. Heißt, es gibt ein gewisses "dependency tracking" zwischen Optimierungen. Je mehr codegen-units, desto schlechtere Performance, aber schnellere Build-Zeit. Man kann alles mit

codegen-units=1

bauen, was die optimale Performance ergibt, aber extrem langsam ist.

Zudem ist es normal, dass Rust-Projekte extrem viele dependencies haben. Ich hatte ein automatisches Bild-Reprojektions-Tool für die Arbeit in Rust geschrieben, 180 dependencies. Ein anderes Projekt von mir hat 250 - 300 dependencies. Wenn man da die ganze Zeit für Typ-checking und Borrow-checking vertrödelt (welches ja vorher schon geschehen ist), macht das halt irgendwann keinen Spaß mehr, 20 Sekunden für ein neues Build zu warten. Insofern ist es einfach ein Schritt vorwärts / aufholen zu anderen Compilern.

Bewerten
- +