Scala.io 2013 - M’enfin Scalac, où glandes-tu encore ?
•
1 j'aime•2,131 vues
Scala est un super langage. Vraiment, son système de types extrêmement expressif permet de prouver tout un tas de propriétés sur notre cher code. D’ailleurs, on sent bien que le compilateur Scalac travaille pour nous. Qu’il travaille encore et encore… Certains vont jusqu’à dire que le réchauffement climatique s’est emballé depuis que Scala a commencé à rencontrer le succès. Bref, parfois nous aimerions que Scalac aille un peu plus vite. Ou au moins savoir où Scalac passe son temps, et si le dernier gâteau ajouté à notre architecture est responsable des 17 minutes de build de notre projet de 100 lignes. Cette présentation essaiera de faire un bilan des pratiques qui peuvent améliorer ou au contraire dégrader le temps de compilations, en partant des généralités (le CPU, par exemple - si si) et en allant jusqu’à la pose de sondes Aspectj afin de savoir quels sont les fichiers qui sont les plus gourmands en temps de compilation.
Recommandé
Recommandé
Contenu connexe
Similaire à Scala.io 2013 - M’enfin Scalac, où glandes-tu encore ?
Similaire à Scala.io 2013 - M’enfin Scalac, où glandes-tu encore ? (20)
Plus de RUDDER
Plus de RUDDER (20)
Scala.io 2013 - M’enfin Scalac, où glandes-tu encore ?
- 1. 2013-10-{24,25} M’enfin Scalac, où glandes-tu encore ? François ARMAND Directeur R&D - Normation far@normation.com
- 2. Speaker François @fanf42 ARMAND far@normation.com Lead-dev Co-founder Scala since... (for personal projects) Scala PSUG !!! Projet LaFoSec Sécurité des langages fonctionnels (Scala from the point of view of IT security) French paper for the Agence Nationnal de la Sécurité de SI (ANSSI) 2 http://www.ssi.gouv.fr/fr/anssi/publications/publications -scientifiques/autres-publications/lafosec-securite-et-la ngages-fonctionnels.html
- 3. De quoi va-t-on parler ? 3
- 4. De quoi va-t-on parler ? ▣ ▣ 4 Pourquoi, mais pourquoi Scalac est-il si lent ? En fait, est-ce que j'y peux quelque chose ?
- 5. De quoi va-t-on parler ? ▣ RAM, CPU et I/O ▣ ▣ ▣ Améliorer ▣ Espérer ? Options de la JVM ▣ Inférence de type et autres features ▣ Sondes AspectJ ▣ Uniquement compilation ! ▣ 5 Comprendre Pas de miracles
- 6. 2013-10-{24,25} Scalac : tous unis pour le réchauffement climatique
- 7. Contentions : pourquoi ça rame ? CPU ▣ Bien sûr, ca joue ■ ■ Test de temps de compilation d'un projet Scala pour différent CPU CPU plus puissant ⇒ compilation plus rapide ! https://groups.google.com/forum/#!topic/scala-user/PJbQefbsn0M https://gist.github.com/DaveGit/5204178 ▣ JVM : Temps de chauffe ! ■ 7 JIT : compilation, optimization...
- 8. Contentions : pourquoi ça rame ? ▣ Scalac est une application JavaJVM : ■ ■ Ou de GC. ■ Ou de quantité d'objets générés. ■ ▣ en fait, c'est toujours une question de RAM. Enfin, c'est la même chose. Perception de lenteur : tuner le temps de lancement ! RAM 8
- 9. Contentions : pourquoi ça rame ? ▣ Chargement de Jar / Class ▣ Écriture de logs (console) ▣ Génération de Bytecode ▣ Ecriture de .class I/O 9
- 10. Contentions : pourquoi ça rame ? CPU RAM 10 I/O
- 11. 2013-10-{24,25} Scalac : tous unis pour le réchauffement climatique Fatal Features
- 12. Performances de Scalac ▣ On ne parle que de ça ■ Stack overflow & Martin Odersky (2010) □ ■ Bill Venners : project compiletime (2013) □ ■ http://stackoverflow.com/questions/3606591/why-does-intellij-idea-compile-scala-so-slowly/3612212#3612212 http://www.artima.com/articles/compile_time.html Des dizaines d'emails sur scala-internal □ □ Paul Phillips : obsédé par les performances et les métriques James Iry,Grzegorz Kossakowski, Simon Ochsenreither, Rex Kerr et tous ceux que j'oublie … ■ ■ 12 Miguel Garcia : compiler corner reloaded Et des milliards d'utilisateurs Scala.
- 13. Fonctionnalités fatales Start-up ■ ■ ▣ Odersky : Greater startup overhead ■ ■ ■ 13 Parcours du Classpath □ Recherche des roots Taille / nombre de jar Scalac itself consists of a LOT loaded and jit-compiled of classes which have to be Scalac has to search the classpath for all root packages and files. Depending on the size of your classpath this can take one to three extra seconds. Overall, expect a startup overhead of scalac of 4-8 seconds, longer if you run it the first time so disk-caches are not filled.
- 14. Fonctionnalités fatales ▣ Chaque recherche d'implicit doit vérifier UNE UNIQUE solution Parcours de l'ensemble des possibilités A CHAQUE FOIS ■ Jeu : construire une HLIST (Shapeless) de plus en plus grande. Système de type ■ Inférences de type ■ Recheche d'implicits The point is that we are outside the realm of anyone's conscious expectations. It's like taking a toy car on a journey to the moon. Maybe the car's plastic will make it through the Van Allen belt, maybe it won't but regardless of outcome, there is no expected behavior. There is only observed behavior. https://groups.google.com/d/msg/shapeless-dev/HvV63toSBNM/omphOda7-jcJ https://docs.google.com/spreadsheet/ccc?key=0Avj3prhoBpnsdGM3TUY2ZWpaLUZPcWpUcXBxXzVDWFE#gid=0 14
- 15. Fonctionnalités fatales ▣ Scalac n'est pas I/O bounded ■ ▣ (bémol pour système de fichiers archaïque) Mais c'est un bon indicateur de la complexité ■ Et du stress généré sur le GC Nombre de classes générées ■ Nombre de fonctions, ■ X 26 lazy val, … X 42 Très grande majorité de petits fichiers ( < 1ko ) 15
- 16. Fonctionnalités fatales ▣ « project compile time » ■ ▣ http://www.artima.com/articles/compile_time.html "the compiler must insert forwarding methods for all the methods declared in the trait into the body of the subclass" ▣ ▣ 16 -optimize spécialisation ▣ Héritage depuis un trait Énormément de travail supplémentaire pour le compilateur
- 17. Fonctionnalités fatales Start-up ■ ■ Parcours du Classpath □ Recherche des roots Taille / nombre de jar Nombre de classes générées ■ Nombre de fonctions, ■ ■ Inférences de type ■ Recheche d'implicits Héritage depuis un trait lazy val, … ▣ -optimize ▣ 17 Système de type spécialisation Solution : ne pas faire de Scala !
- 19. Fonctionnalités fatales Start-up ■ ■ ▣ Parcours du Classpath □ Recherche des roots Taille / nombre de jar JVM □ □ ■ Headius (JRuby fame) Paul Phillips (Alpaca farmer) https://groups.google.com/forum/#!topic/scala-internals/rqtMmPEgdOM Linux : Regenerate the shared archive !!! □ ■ java -Xshare:dump JVM Options (YMMV): □ □ 19 https://github.com/jruby/jruby/wiki/Improving-startup-time Tuning de GC quasi-sans effet -Xmx3g -Xms3g -XX:+TieredCompilation -XX:ReservedCodeCacheSize=256m -XX:MaxPermSize=384m -XX:+UseNUMA -XX:+UseParallelGC
- 20. Fonctionnalités fatales Système de type ■ ▣ Pas de solution simple ■ ▣ Recheche d'implicits Sauf les cas triviaux, où ajouter des informations de type résout le souci Se priver de ScalaZ, Shapeless, Specs2, etc ? Identifier un fichier qui prend significativement plus de temps ■ Sondes AspectJ ou timing à la main □ □ □ 20 ■ Limiter le nombre d'implicit dans le scope ■ ▣ Inférences de type https://github.com/gkossakowski/scalac-aspects http://blog.normation.com/en/2013/01/29/per-file-compilation-time-in-a-scalamaven-project/ https://groups.google.com/forum/#!topic/scala-internals/lP0m3jJH4to
- 21. Fonctionnalités fatales Nombre de classes générées ■ ■ 21 ▣ Faire du Java ? ▣ Espérer un meilleur futur ? Nombre de fonctions, lazy val, … ■ Java 8 / Closures ?
- 22. Fonctionnalités fatales ▣ Mixer le trait avec une classe ▣ Puis hériter cette classe ailleurs 22 Héritage depuis un trait
- 23. Fonctionnalités fatales ▣ Pas de solution « utilisateur » au niveau code ■ ■ ▣ Ne pas les utiliser par défaut Mettre en place des profils de CI spécialisés Espérer un futur meilleur? ▣ ▣ 23 -optimize spécialisation
- 25. Performances de Scalac ▣ On ne parle que de ça ■ Stack overflow & Martin Odersky (2010) □ ■ http://stackoverflow.com/questions/3606591/why-does-intellij-idea-compile-scala-so-slowly/3612212#3612212 Bill Venners : project compiletime (2013) □ ■ Typesafe est au courant http://www.artima.com/articles/compile_time.html Des dizaines d'emails sur scala-internal □ □ Paul Phillips : obsédé par les performances et les métriques James Iry,Grzegorz Kossakowski, Simon Ochsenreither, Rex Kerr et tous ceux que j'oublie … ■ ■ 25 Miguel Garcia : compiler corner reloaded Et des milliards d'utilisateurs Scala.
- 26. Scala 2.11 : better compilation performances ▣ Amélioration massive de la mémoire consommée par Scalac ■ 26 Backporté en Scala 10.3
- 27. Scala 2.11 : better compilation performances ▣ Réécriture des Class path (Flatpath) ■ Structure de données plus simple ■ Load/Scan de Jar parallélisable ■ Beaucoup plus rapide (~ Java : plusieurs => 200ms) □ □ 27 https://groups.google.com/forum/#!topic/scala-internals/rNsXhyojHUI https://groups.google.com/forum/#!topic/scala-internals/xgb5YbKvQcw
- 28. Scala 2.11 : better compilation performances ▣ Nouveau backend d'émission de bytecode ■ Miguel Garcia : http://magarciaepfl.github.io/scala/ □ https://groups.google.com/forum/#!topic/scala-internals/UqEMRRdj2oY ■ ■ Bytecode généré plus compact ■ Plus d'optimisation, simple et déterministes, possibles ■ 28 10-20% plus rapide Des licornes !
- 29. Et pour le futur ? ▣ Encore pleins de nouvelles choses prévues pour la suite ! https://groups.google.com/forum/#!topic/scala-internals/yCU04A2HoDY 29