Vitesse de compilation Java vs vitesse de compilation Scala

Je programme dans Scala depuis un moment et j'aime ça mais une chose qui me gêne est le temps qu'il faut pour compiler des programmes. Cela semble être une petite chose, mais avec Java, je pourrais apporter de petites modifications à mon programme, cliquer sur le bouton Exécuter dans netbeans, et BOOM, il est en cours d'exécution, et avec le temps, la compilation dans scala semble prendre beaucoup de temps. J'ai entendu dire qu'avec de nombreux grands projets, un langage de script devient très important en raison du temps de compilation, un besoin que je n'ai pas vu surgir lorsque j'utilisais Java.

Mais je viens de Java qui, d'après ce que je comprends, est plus rapide que tout autre langage compilé, et rapide à cause des raisons pour lesquelles je suis passé à Scala (c'est un langage très simple).

Je voulais donc demander, puis-je rendre Scala compiler plus rapidement et scalac sera-t-il toujours aussi rapide que javac?

Le compilateur Scala est plus sophistiqué que celui de Java, fournissant une inférence de type, une conversion implicite et un système de type beaucoup plus puissant. Ces fonctionnalités ne sont pas gratuites, donc je ne m'attendrais pas à ce que scalac soit aussi rapide que javac. Cela reflète un compromis entre le programmeur effectuant le travail et le compilateur effectuant le travail.

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

Martin Odersky fournit beaucoup plus de détails dans sa réponse.

Il y a deux aspects à la (manque de) vitesse du compilateur Scala.

1. Frais généraux de démarrage plus importants

   • Scalac lui-même se compose de BEAUCOUP de classes qui doivent être chargées et compilées jit

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

   Dans l'ensemble, attendez-vous à une surcharge de démarrage du scalac de 4 à 8 secondes, plus longue si vous l'exécutez la première fois afin que les caches de disque ne soient pas remplis.

   La réponse de Scala à la surcharge de démarrage est d'utiliser fsc ou de faire de la construction continue avec sbt. IntelliJ doit être configuré pour utiliser l'une ou l'autre option, sinon sa surcharge, même pour les petits fichiers, est déraisonnablement importante.

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 faire deux vérifications de type; une fois selon les règles de Scala et une seconde fois après l'effacement selon les règles de Java.

   • Outre la vérification de type, 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 de bytecode et l'écriture de classe prennent du temps.

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

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

Vous devez savoir que la compilation Scala prend au moins un ordre de grandeur plus longue que Java à compiler. Les raisons en sont les suivantes:

1. Conventions de dénomination (un fichier XY.scalafichier n'a pas besoin de contenir une classe appelée XYet peut contenir plusieurs classes de niveau supérieur). Le compilateur peut donc avoir à rechercher plus de fichiers source pour trouver un identifiant de classe / trait / objet donné.
2. Implicits - l'utilisation intensive des implicits signifie que le compilateur doit rechercher toute conversion implicite dans la portée pour une méthode donnée et les classer pour trouver la "bonne". ( c'est-à-dire que le compilateur a un domaine de recherche massivement augmenté lors de la localisation d'une méthode. )
3. Le système de type - le système de type scala est bien plus compliqué que celui de Java et prend donc plus de temps CPU.
4. Inférence de type - l'inférence de type est coûteuse en calcul et un travail qui javacn'a pas à faire du tout
5. scalaccomprend un simulateur 8 bits d'une station de combat entièrement armée et opérationnelle, visible à l'aide de la combinaison de touches magiques CTRL-ALT-F12 pendant la phase de compilation GenICode .

La meilleure façon de faire Scala est avec IDEA et SBT. Configurez un projet SBT élémentaire (ce qu'il fera pour vous, si vous le souhaitez) et exécutez-le en mode de compilation automatique (commande~compile ) et lorsque vous enregistrez votre projet, SBT le recompilera.

Vous pouvez également utiliser le plug-in SBT pour IDEA et attacher une action SBT à chacune de vos configurations d'exécution. Le plug-in SBT vous offre également une console SBT interactive dans IDEA.

Dans tous les cas (SBT s'exécutant en externe ou plug-in SBT), SBT reste en cours d'exécution et ainsi toutes les classes utilisées dans la construction de votre projet sont "réchauffées" et JIT-ed et la surcharge de démarrage est éliminée. De plus, SBT ne compile que les fichiers source qui en ont besoin. C'est de loin le moyen le plus efficace de créer des programmes Scala.

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

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

L'autre solution consiste à intégrer fsc - compilateur hors ligne rapide pour le langage Scala 2 - (comme illustré dans ce billet de blog ) en tant que générateur dans votre IDE.

Mais pas directement dans Eclipse, comme le mentionne 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 sous la 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 me le rappelle Jackson Davis dans les commentaires:

sbt (Simple build Tool) inclut également une sorte de compilation "incrémentale" (par exécution déclenchée ), même si elle n'est pas parfaite , et une compilation incrémentielle améliorée est en cours pour la prochaine version 0.9 sbt.

Utilisez fsc - c'est un compilateur scala rapide qui se trouve en tâche de fond et qui n'a pas besoin d'être chargé en permanence. Il peut réutiliser l'instance précédente du compilateur.

Je ne sais pas si le plugin Netbeans scala prend en charge fsc (la documentation le dit), mais je n'ai pas pu le faire fonctionner. Essayez les versions nocturnes du plugin.

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 rechargerait 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'implicits (le compilateur doit s'assurer qu'il n'y a pas plus d'un seul implicite pour la même conversion afin d'exclure les ambiguïtés) peuvent occuper le compilateur. Il peut donc être judicieux de gérer les implicits avec précaution.

S'il n'est pas nécessaire que ce soit 100% Scala, mais aussi quelque chose de similaire, vous pouvez essayer Kotlin .

- Oliver

Je suis sûr que ce sera voté à la baisse, mais une rotation extrêmement rapide ne favorise pas toujours 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é). Cela 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 tout en améliorant votre productivité et la qualité de votre travail.

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