scala.io 2013 - m’enfin scalac, où glandes-tu encore ?
DESCRIPTION
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.TRANSCRIPT
2013-10-{24,25}
M’enfin Scalac, où glandes-tu encore ?
François ARMANDDirecteur R&D - Normation
2
Speaker
[email protected] François @fanf42 ARMAND
Scala since...
PSUG !!!
(for personal projects)
Co-founder Lead-dev
Projet LaFoSecSé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)
http://www.ssi.gouv.fr/fr/anssi/publications/publications-scientifiques/autres-publications/lafosec-securite-et-langages-fonctionnels.html
Scala
3
De quoi va-t-on parler ?
4
De quoi va-t-on parler ?
▣ 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
▣ Options de la JVM
▣ Inférence de type et autres features
▣ Sondes AspectJ
▣ RAM, CPU et I/O
▣ Options de la JVM
▣ Inférence de type et autres features
▣ Sondes AspectJ
▣ Comprendre
▣ Améliorer
▣ Espérer ?
▣ Uniquement compilation !
▣ Pas de miracles
▣ Uniquement compilation !
▣ Pas de miracles
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 !■ JIT : compilation, optimization...
8
Contentions : pourquoi ça rame ?
RAM
▣ Scalac est une application JavaJVM :
■ en fait, c'est toujours une question de RAM.
■ Ou de GC.
■ Ou de quantité d'objets générés.
■ Enfin, c'est la même chose.
▣ Perception de lenteur : tuner le temps de lancement !
9
Contentions : pourquoi ça rame ?
I/O
▣ Chargement de Jar / Class
▣ Écriture de logs (console)
▣ Génération de Bytecode
▣ Ecriture de .class
10
Contentions : pourquoi ça rame ?
CPU
RAM I/O
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)□ http://stackoverflow.com/questions/3606591/why-does-intellij-idea-compile-scala-so-slowly/3612212#3612212
■ Bill Venners : project compiletime (2013)□ 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 …
■ Miguel Garcia : compiler corner reloaded
■ Et des milliards d'utilisateurs Scala.
13
Fonctionnalités fatales
▣ Odersky : Greater startup overhead
■ Scalac itself consists of a LOT of classes which have to be loaded and jit-compiled
■ 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.
Start-up■ Parcours du Classpath
□ Recherche des roots■ Taille / nombre de jar
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.
https://docs.google.com/spreadsheet/ccc?key=0Avj3prhoBpnsdGM3TUY2ZWpaLUZPcWpUcXBxXzVDWFE#gid=0
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
Système de type■ Inférences de type
■ Recheche d'implicits
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
X 26
X 42Très grande majorité de petits fichiers ( < 1ko )
Nombre de classes générées
■ Nombre de fonctions,
■ lazy val, …
16
Fonctionnalités fatales
Héritage depuis un trait
▣ « 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"
▣ -optimize▣ spécialisation
▣ Énormément de travail supplémentaire pour le compilateur
17
Nombre de classes générées
■ Nombre de fonctions,
■ lazy val, …
Héritage depuis un trait
Start-up■ Parcours du Classpath
□ Recherche des roots■ Taille / nombre de jar
Fonctionnalités fatales
Solution : ne pas faire de Scala !▣ -optimize▣ spécialisation
Système de type■ Inférences de type
■ Recheche d'implicits
2013-10-{24,25}
Améliorer les choses(?)
19
▣ JVM
□ Headius (JRuby fame) https://github.com/jruby/jruby/wiki/Improving-startup-time
□ Paul Phillips (Alpaca farmer) https://groups.google.com/forum/#!topic/scala-internals/rqtMmPEgdOM
■ Linux : Regenerate the shared archive !!! □ java -Xshare:dump
■ JVM Options (YMMV):□ Tuning de GC quasi-sans effet□ -Xmx3g -Xms3g -XX:+TieredCompilation
-XX:ReservedCodeCacheSize=256m -XX:MaxPermSize=384m -XX:+UseNUMA -XX:+UseParallelGC
Fonctionnalités fatales
Start-up■ Parcours du Classpath
□ Recherche des roots■ Taille / nombre de jar
20
Fonctionnalités fatales
▣ Pas de solution simple
■ Sauf les cas triviaux, où ajouter des informations de type résout le souci
▣ Limiter le nombre d'implicit dans le scope
■ Se priver de ScalaZ, Shapeless, Specs2, etc ?
▣ Identifier un fichier qui prend significativement plus de temps
■ Sondes AspectJ ou timing à la main
□ https://github.com/gkossakowski/scalac-aspects
□ http://blog.normation.com/en/2013/01/29/per-file-compilation-time-in-a-scala-maven-project/
□ https://groups.google.com/forum/#!topic/scala-internals/lP0m3jJH4to
Système de type■ Inférences de type
■ Recheche d'implicits
21
Fonctionnalités fatales
▣ Faire du Java ?
▣ Espérer un meilleur futur ?
■ Java 8 / Closures ?
Nombre de classes générées
■ Nombre de fonctions,
■ lazy val, …
22
Fonctionnalités fatales
▣ Mixer le trait avec une classe
▣ Puis hériter cette classe ailleursHé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?
▣ -optimize▣ spécialisation
2013-10-{24,25}
Un meilleur futur ?
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)□ 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 …
■ Miguel Garcia : compiler corner reloaded
■ Et des milliards d'utilisateurs Scala.
Typesafe est au courant
26
Scala 2.11 : better compilation performances
▣ Amélioration massive de la mémoire consommée par Scalac
■ 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)□ 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
■ 10-20% plus rapide
■ Bytecode généré plus compact
■ Plus d'optimisation, simple et déterministes, possibles
■ Deslicornes !
29
Et pour le futur ?
▣ Encore pleins de nouvelles choses prévues pour la suite !
https://groups.google.com/forum/#!topic/scala-internals/yCU04A2HoDY
2013-10-{24,25}
Questions ?