Télécharger en tant que PDF, PPTX
Téléchargé parRUDDER
Scala.io 2013 - M’enfin Scalac, où glandes-tu encore ?
Le document traite des problèmes de performance de la compilation avec scalac, explorant les facteurs de ralentissement tels que la RAM, le CPU et les entrées/sorties. Il souligne l'importance de la recherche d'implicites et de l'inférence de types, tout en proposant des solutions potentielles pour améliorer la rapidité du compilateur. Des évolutions de Scala, notamment la version 2.11, sont évoquées, apportant des améliorations significatives dans les performances de compilation.
Scala.io 2013 - M’enfin Scalac, où glandes-tu encore ?
- 1. 2013-10-{24,25} M’enfin Scalac, où glandes-tuencore ? François ARMAND Directeur R&D - Normation far@normation.com
- 2. Speaker François @fanf42 ARMAND far@normation.com Lead-dev Co-founder Scalasince... (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-onparler ? 3
- 4. De quoi va-t-onparler ? ▣ ▣ 4 Pourquoi, mais pourquoi Scalac est-il si lent ? En fait, est-ce que j'y peux quelque chose ?
- 5. De quoi va-t-onparler ? ▣ 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 unispour le réchauffement climatique
- 7. Contentions : pourquoi çarame ? 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 çarame ? ▣ 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 çarame ? ▣ Chargement de Jar / Class ▣ Écriture de logs (console) ▣ Génération de Bytecode ▣ Ecriture de .class I/O 9
- 10. Contentions : pourquoi çarame ? CPU RAM 10 I/O
- 11. 2013-10-{24,25} Scalac : tous unispour le réchauffement climatique Fatal Features
- 12. Performances de Scalac ▣ Onne 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 : Greaterstartup 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 recherched'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'estpas 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 compiletime » ■ ▣ 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 duClasspath □ 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 !
- 18.
- 19. Fonctionnalités fatales Start-up ■ ■ ▣ Parcours duClasspath □ 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 detype ■ ▣ 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 declasses 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 letrait avec une classe ▣ Puis hériter cette classe ailleurs 22 Héritage depuis un trait
- 23. Fonctionnalités fatales ▣ Pas desolution « 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
- 24.
- 25. Performances de Scalac ▣ Onne 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 : bettercompilation performances ▣ Amélioration massive de la mémoire consommée par Scalac ■ 26 Backporté en Scala 10.3
- 27. Scala 2.11 : bettercompilation 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 : bettercompilation 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 lefutur ? ▣ Encore pleins de nouvelles choses prévues pour la suite ! https://groups.google.com/forum/#!topic/scala-internals/yCU04A2HoDY 29
- 30.