Vitesse de compilation de Java par rapport à celle de Scala

Question

Je programme en Scala depuis un certain temps et j'aime ce langage, mais le temps nécessaire à la compilation des programmes m'ennuie. Cela semble être une petite chose, mais avec Java, je pouvais apporter de petites modifications à mon programme, cliquer sur le bouton d'exécution dans Netbeans, et BOOM, il fonctionne, et au fil du temps la compilation en Scala semble consommer beaucoup de temps. J'ai entendu dire que dans de nombreux grands projets, un langage de script devient très important en raison du temps que prend la compilation, un besoin que je ne voyais pas apparaître lorsque j'utilisais Java.

Mais je viens de Java qui, d'après ce que j'ai compris, est plus rapide que n'importe quel autre langage compilé, et c'est pour cette raison que je suis passé à Scala (c'est un langage très simple).

Je voulais donc demander si je peux faire en sorte que Scala compile plus rapidement et si scalac sera un jour aussi rapide que javac.

Answer 1

Le compilateur Scala est plus sophistiqué que celui de Java. Il permet l'inférence de types, la conversion implicite et un système de types beaucoup plus puissant. Ces fonctionnalités ne sont pas gratuites, donc je ne m'attends pas à ce que Scala soit un jour aussi rapide que Java. Ceci reflète un compromis entre le programmeur qui fait le travail et le compilateur qui fait le travail.

Cela dit, les temps de compilation se sont déjà nettement améliorés en passant de Scala 2.7 à Scala 2.8, et je m'attends à ce que ces améliorations se poursuivent maintenant que la poussière est retombée sur la 2.8. Cette page documente certains des efforts et idées en cours pour améliorer les performances du compilateur Scala.

En une réponse (maintenant supprimée) à une question maintenant close Martin Odersky est entré dans le détail :

Le (manque de) vitesse du compilateur Scala présente deux aspects.

1. Frais généraux de démarrage plus élevés

   • Scalac lui-même est constitué de BEAUCOUP de classes qui doivent être chargées et compilées en jit.

   • Scalac doit rechercher dans le classpath tous les paquets et fichiers Root. En fonction de la taille de votre classpath, cela peut prendre une à trois secondes supplémentaires.

   Dans l'ensemble, attendez-vous à un temps de démarrage de scalac de 4 à 8 secondes, plus long si vous l'exécutez pour la première fois afin de ne pas remplir les caches disques. si vous le lancez la première fois pour que les caches disques ne soient pas remplis.

   La réponse de Scala à l'overhead de démarrage est soit d'utiliser fsc soit de faire du construction continue avec sbt. IntelliJ doit être configuré pour utiliser l'une ou l'autre de ces options, sinon sa surcharge, même pour des déraisonnablement élevé.

2. Vitesse de compilation plus lente. Scalac gère environ 500 à 1000 lignes/sec. Javac gère environ 10 fois cela. Il y a plusieurs raisons à cela.

   • L'inférence de type est coûteuse, en particulier si elle implique une recherche implicite.

   • Scalac doit effectuer deux fois la vérification des types ; une fois selon les règles de Scala et une seconde fois après effacement selon les règles de Java.

   • Outre la vérification des types, il y a environ 15 étapes de transformation pour passer de Scala à Java, qui prennent toutes du temps.

   • Scala génère généralement beaucoup plus de classes par taille de fichier donnée que Java, en particulier si les idiomes fonctionnels sont fortement utilisés. La génération du bytecode et l'écriture des classes prennent du temps.

   D'un autre côté, un programme Scala de 1000 lignes peut correspondre à un programme Java de 2-3K lignes. 2-3K lignes de programme Java, donc une partie de la vitesse plus lente lorsqu'elle est comptée en lignes par seconde doit être compensée par une plus grande fonctionnalité par ligne.

   Nous travaillons sur des améliorations de vitesse (par exemple en générant des fichiers de classe en parallèle), mais il ne faut pas s'attendre à des miracles dans ce domaine. sur ce front. Scalac ne sera jamais aussi rapide que javac. Je pense que la solution Je crois que la solution résidera dans des serveurs de compilation comme fsc en conjonction avec une bonne analyse des dépendances afin que seul le minimum soit nécessaire. une bonne analyse des dépendances, de sorte que seul l'ensemble minimal de fichiers doive être recompilé. Nous travaillons également sur ce point.

Answer 2

Les dernières révisions de Scala-IDE (Eclipse) sont bien meilleurs pour gérer la compilation incrémentale.

Voir " Quel est le meilleur système de construction Scala ? " pour en savoir plus.

---

L'autre solution consiste à intégrer fsc - Compilateur rapide hors ligne pour le langage Scala 2 - (comme illustré dans cette article de blog ) comme un constructeur dans votre IDE.

Mais pas dans directement Eclipse cependant, comme Daniel Spiewak dans les commentaires :

Vous ne devriez pas utiliser FSC directement dans Eclipse, ne serait-ce que parce qu'Eclipse utilise déjà FSC en surface.
FSC est essentiellement une couche mince au-dessus du compilateur résident qui est précisément le mécanisme utilisé par Eclipse pour compiler les projets Scala.

---

Enfin, comme Jackson Davis rappelle-moi dans les commentaires :

sbt (Outil de construction simple) comprennent également une sorte de compilation "incrémentale" (par le biais de exécution déclenchée ), même s'il n'est pas parfait Une compilation incrémentale améliorée est en cours pour la prochaine version 0.9 de sbt.

Answer 3

Utilice fsc - Il s'agit d'un compilateur Scala rapide qui fonctionne en tâche de fond et ne doit pas être chargé en permanence. Il peut réutiliser l'instance précédente du compilateur.

Je ne suis pas sûr que le plugin scala de Netbeans supporte fsc (la documentation le dit), mais je n'ai pas réussi à le faire fonctionner. Essayez les nightly builds du plugin.

Answer 4

Vous pouvez utiliser le plugin JRebel qui est gratuit pour Scala. Ainsi, vous pouvez en quelque sorte "développer dans le débogueur" et JRebel rechargera toujours la classe modifiée sur place.

J'ai lu quelque part une déclaration de Martin Odersky lui-même où il dit que les recherches d'implicites (le compilateur doit s'assurer qu'il n'y a pas plus d'un seul implicite pour la même conversion afin d'éliminer les ambiguïtés) peuvent occuper le compilateur. C'est donc une bonne idée de manipuler les implicites avec précaution.

Si cela ne doit pas être 100% Scala, mais aussi quelque chose de similaire, vous pouvez donner Kotlin un essai.

-- Oliver

Answer 5

Je suis sûr que ce point fera l'objet d'un vote négatif, mais un délai d'exécution extrêmement rapide n'est pas toujours propice à la qualité ou à la productivité.

Prenez le temps de réfléchir plus attentivement et d'exécuter moins de micro-cycles de développement. Un bon code Scala est plus dense et plus essentiel (c'est-à-dire exempt de détails accessoires et de complexité). Il demande plus de réflexion et cela prend du temps (du moins au début). Vous pouvez bien progresser avec moins de cycles de code / test / débogage qui sont individuellement un peu plus longs et améliorer quand même votre productivité et la qualité de votre travail.

En bref : rechercher un modèle de travail optimal mieux adapté à Scala.