Il y a un truc qui n'apparaît pas dans ton benchmark, c'est que les Integer ont un cache: le boxing va retourner la même instance d'Integer pour un int de la même valeur, entre certaines bornes, et c'est configurable (http://stackoverflow.com/questions/15052216/how-large-is-the-integer-cache). C'est clair que ça reste limité, mais en pratique je pense qu'on y gagne pas mal.
Ca ne change rien sur la perf. Ca permet de ne pas créer trop d'objets, et donc diminuer un peu l'empreinte mémoire et la pression sur le GC, pour les valeurs les plus courantes mais le coût d’exécution est le même. De toute facon si la perf est ton problème, le cache sera toujours beaucoup trop petit.
Autrement l'approche de Scala me semble la plus pragmatique: au niveau du langage il y a des types correspondants aux types primitifs de Java (Int, Long, etc.), mais qui se comportent comme des classes, ont leur propres méthodes, sont utilisables dans les types génériques. Le compilateur se débrouille après pour utiliser les types primitifs au niveau du bytecode (donc pas plus d'overhead).
Je n'écris plus beaucoup de Scala ces derniers temps mais si l'approche semble en effet plus propre, le mécanisme de spécialisation arrive assez vite à ses limites et tu as donc des performances assez imprédictibles pour qui ne sait précisément l'implémentation derrière. Je ne connais pas suffisamment la théorie derrière pour savoir si c'est un problème d'engineering ou théorique.
Du côté de la JVM, on parlait informellement en 2012 d'optimisations pour détecter une suite de box/unbox pour les virer. Identiquement théoriquement je ne sais pas si c'est une jambe de bois.
À ma connaissance aucun langage sur la JVM n'a vraiment résolu le problème et donc que la JVM est le facteur limitant.
[^] # Re: Fin de la pureté de Java
Posté par ckyl . En réponse à la dépêche Java 8 et NetBeans 8 sont disponibles. Évalué à 3.
Ca ne change rien sur la perf. Ca permet de ne pas créer trop d'objets, et donc diminuer un peu l'empreinte mémoire et la pression sur le GC, pour les valeurs les plus courantes mais le coût d’exécution est le même. De toute facon si la perf est ton problème, le cache sera toujours beaucoup trop petit.
Je n'écris plus beaucoup de Scala ces derniers temps mais si l'approche semble en effet plus propre, le mécanisme de spécialisation arrive assez vite à ses limites et tu as donc des performances assez imprédictibles pour qui ne sait précisément l'implémentation derrière. Je ne connais pas suffisamment la théorie derrière pour savoir si c'est un problème d'engineering ou théorique.
Du côté de la JVM, on parlait informellement en 2012 d'optimisations pour détecter une suite de box/unbox pour les virer. Identiquement théoriquement je ne sais pas si c'est une jambe de bois.
À ma connaissance aucun langage sur la JVM n'a vraiment résolu le problème et donc que la JVM est le facteur limitant.