Java-Kompilierungsgeschwindigkeit vs Scala-Kompilierungsgeschwindigkeit

Ich habe eine Weile in Scala programmiert und es gefällt mir, aber eine Sache, die mich ärgert, ist die Zeit, die zum Kompilieren von Programmen benötigt wird. Es scheint eine kleine Sache zu sein, aber mit Java könnte ich kleine Änderungen an meinem Programm vornehmen, auf die Schaltfläche "Ausführen" in Netbeans klicken und BOOM wird ausgeführt, und das Kompilieren in Scala scheint im Laufe der Zeit viel Zeit in Anspruch zu nehmen. Ich höre, dass bei vielen großen Projekten eine Skriptsprache aufgrund des Zeitaufwands beim Kompilieren sehr wichtig wird, ein Bedarf, den ich bei der Verwendung von Java nicht gesehen habe.

Aber ich komme aus Java, das meines Wissens schneller ist als jede andere kompilierte Sprache und aus den Gründen, aus denen ich zu Scala gewechselt bin (es ist eine sehr einfache Sprache), schnell ist.

Also wollte ich fragen, ob ich Scala schneller kompilieren kann und ob Scalac jemals so schnell wie Javac sein wird.

Der Scala-Compiler ist komplexer als der von Java und bietet Typinferenz, implizite Konvertierung und ein viel leistungsfähigeres Typsystem. Diese Funktionen sind nicht kostenlos, daher würde ich nicht erwarten, dass Scalac jemals so schnell wie Javac ist. Dies spiegelt einen Kompromiss zwischen dem Programmierer, der die Arbeit erledigt, und dem Compiler, der die Arbeit erledigt, wider.

Trotzdem haben sich die Kompilierungszeiten von Scala 2.7 auf Scala 2.8 bereits merklich verbessert, und ich gehe davon aus, dass sich die Verbesserungen fortsetzen werden, sobald sich der Staub auf 2.8 gelegt hat. Diese Seite dokumentiert einige der laufenden Bemühungen und Ideen zur Verbesserung der Leistung des Scala-Compilers.

Martin Odersky liefert in seiner Antwort viel mehr Details.

Die (fehlende) Geschwindigkeit des Scala-Compilers hat zwei Aspekte.

1. Höherer Startaufwand

   • Scalac selbst besteht aus vielen Klassen, die geladen und jit-kompiliert werden müssen

   • Scalac muss den Klassenpfad nach allen Root-Paketen und Dateien durchsuchen. Abhängig von der Größe Ihres Klassenpfads kann dies ein bis drei zusätzliche Sekunden dauern.

   Erwarten Sie insgesamt einen Startaufwand für Scalac von 4 bis 8 Sekunden, der länger ist, wenn Sie ihn zum ersten Mal ausführen, damit die Festplatten-Caches nicht gefüllt werden.

   Scalas Antwort auf den Startaufwand besteht darin, entweder fsc zu verwenden oder kontinuierlich mit sbt zu erstellen. IntelliJ muss für die Verwendung beider Optionen konfiguriert werden, da sonst der Overhead selbst für kleine Dateien unangemessen groß ist.

2. Langsamere Kompilierungsgeschwindigkeit. Scalac verwaltet ungefähr 500 bis 1000 Linien / Sek. Javac schafft das ungefähr zehnmal. Dafür gibt es mehrere Gründe.

   • Typinferenz ist kostspielig, insbesondere wenn es sich um eine implizite Suche handelt.

   • Scalac muss die Typprüfung zweimal durchführen. einmal nach den Regeln von Scala und ein zweites Mal nach dem Löschen nach den Regeln von Java.

   • Neben der Typprüfung gibt es ungefähr 15 Transformationsschritte von Scala nach Java, die alle Zeit in Anspruch nehmen.

   • Scala generiert in der Regel viel mehr Klassen pro Dateigröße als Java, insbesondere wenn häufig funktionale Redewendungen verwendet werden. Die Bytecode-Generierung und das Schreiben von Klassen brauchen Zeit.

   Auf der anderen Seite könnte ein Scala-Programm mit 1000 Zeilen einem Java-Programm mit 2-3 KB Zeilen entsprechen, sodass ein Teil der langsameren Geschwindigkeit, wenn sie in Zeilen pro Sekunde gezählt wird, gegen mehr Funktionalität pro Zeile abgewogen werden muss.

   Wir arbeiten an Geschwindigkeitsverbesserungen (zum Beispiel durch paralleles Generieren von Klassendateien), aber an dieser Front kann man keine Wunder erwarten. Scalac wird niemals so schnell sein wie Javac. Ich glaube, die Lösung wird darin bestehen, Server wie fsc in Verbindung mit einer guten Abhängigkeitsanalyse zu kompilieren, sodass nur der minimale Satz von Dateien neu kompiliert werden muss. Daran arbeiten wir auch.

Sie sollten sich bewusst sein, dass die Kompilierung von Scala mindestens eine Größenordnung länger dauert als die von Java. Die Gründe dafür sind folgende:

1. Namenskonventionen (eine Dateidatei XY.scalamuss keine aufgerufene Klasse XYenthalten und kann mehrere Klassen der obersten Ebene enthalten). Der Compiler muss daher möglicherweise mehr Quelldateien durchsuchen, um eine bestimmte Klassen- / Merkmals- / Objektkennung zu finden.
2. Implicits - Die häufige Verwendung von Implicits bedeutet, dass der Compiler jede implizite Konvertierung im Gültigkeitsbereich nach einer bestimmten Methode durchsuchen und sie bewerten muss, um die "richtige" zu finden. ( dh der Compiler hat beim Auffinden einer Methode eine massiv vergrößerte Suchdomäne. )
3. Das Typsystem - das Scala-Typsystem ist viel komplizierter als das von Java und benötigt daher mehr CPU-Zeit.
4. Typinferenz - Typinferenz ist rechenintensiv und ein Job, der javacüberhaupt nicht erledigt werden muss
5. scalacEnthält einen 8-Bit-Simulator einer voll bewaffneten und einsatzbereiten Kampfstation, der während der GenICode- Kompilierungsphase mit der magischen Tastenkombination STRG-ALT-F12 angezeigt werden kann.

Der beste Weg, um Scala zu machen, ist mit IDEA und SBT. Richten Sie ein elementares SBT-Projekt ein (was es für Sie erledigt, wenn Sie möchten) und führen Sie es im automatischen Kompilierungsmodus (Befehl ~compile) aus. Wenn Sie Ihr Projekt speichern, kompiliert SBT es erneut.

Sie können auch das SBT-Plug-In für IDEA verwenden und jeder Ihrer Ausführungskonfigurationen eine SBT-Aktion hinzufügen. Das SBT-Plug-In bietet Ihnen auch eine interaktive SBT-Konsole innerhalb von IDEA.

In beiden Fällen (SBT wird extern ausgeführt oder SBT-Plug-In) wird SBT weiterhin ausgeführt, sodass alle beim Erstellen Ihres Projekts verwendeten Klassen "aufgewärmt" und JIT-ed werden und der Startaufwand entfällt. Darüber hinaus kompiliert SBT nur Quelldateien, die es benötigen. Dies ist bei weitem der effizienteste Weg, um Scala-Programme zu erstellen.

Die neuesten Versionen von Scala-IDE (Eclipse) verwalten die inkrementelle Kompilierung viel besser.

Weitere Informationen finden Sie unter " Was ist das beste Scala-Build-System? ".

Die andere Lösung besteht darin, fsc - Fast Offline Compiler für die Scala 2-Sprache - (wie in diesem Blog-Beitrag dargestellt ) als Builder in Ihre IDE zu integrieren.

Aber nicht direkt in Eclipse, wie Daniel Spiewak in den Kommentaren erwähnt:

Sie sollten FSC nicht direkt in Eclipse verwenden, schon allein deshalb, weil Eclipse FSC bereits unter der Oberfläche verwendet.
FSC ist im Grunde eine dünne Schicht über dem residenten Compiler. Dies ist genau der Mechanismus, den Eclipse zum Kompilieren von Scala-Projekten verwendet.

Zum Schluss, wie Jackson Davis mich in den Kommentaren erinnert:

sbt (Simple Build Tool) enthält auch eine Art "inkrementelle" Kompilierung (durch ausgelöste Ausführung ), obwohl diese nicht perfekt ist. Für die kommende Version 0.9 sbt ist eine erweiterte inkrementelle Kompilierung in Arbeit.

Verwenden Sie fsc - es ist ein schneller Scala-Compiler, der als Hintergrundaufgabe fungiert und nicht ständig geladen werden muss. Es kann die vorherige Compilerinstanz wiederverwenden.

Ich bin nicht sicher, ob das Netbeans-Scala-Plugin fsc unterstützt (Dokumentation sagt es), aber ich konnte es nicht zum Laufen bringen. Versuchen Sie es mit nächtlichen Builds des Plugins.

Sie können das JRebel-Plugin verwenden, das für Scala kostenlos ist. Sie können sich also sozusagen im Debugger entwickeln, und JRebel lädt die geänderte Klasse immer sofort neu.

Ich habe irgendwo eine Aussage von Martin Odersky selbst gelesen, in der er sagt, dass die Suche nach Impliziten (der Compiler muss sicherstellen, dass es nicht mehr als ein einziges Implizit für dieselbe Konvertierung gibt, um Mehrdeutigkeiten auszuschließen) den Compiler beschäftigen kann. Daher ist es möglicherweise eine gute Idee, mit Implikationen vorsichtig umzugehen.

Wenn es nicht 100% Scala sein muss, sondern auch etwas Ähnliches, können Sie Kotlin ausprobieren.

- Oliver

Ich bin sicher, dass dies abgelehnt wird, aber eine extrem schnelle Abwicklung ist nicht immer förderlich für Qualität oder Produktivität.

Nehmen Sie sich Zeit zum Nachdenken und führen Sie weniger Entwicklungsmikrozyklen aus. Guter Scala-Code ist dichter und wichtiger (dh frei von zufälligen Details und Komplexität). Es erfordert mehr Gedanken und das braucht Zeit (zumindest zuerst). Sie können mit weniger Code- / Test- / Debug-Zyklen, die individuell etwas länger sind, gute Fortschritte erzielen und dennoch Ihre Produktivität und die Qualität Ihrer Arbeit verbessern.

Kurzum: Suchen Sie ein optimales Arbeitsmuster, das besser zu Scala passt.