Développement Java
  1. Développement Java
  3. Performance de Nashorn sur les JDK 9 et 10
Intereting Posts
JAVA: Manières de remplir un cadre. add (), setContentPane (), getContentPane () Comment convertir les clés de carte de hachage en liste? Lorsque j’utilise getResultList () d’une requête JPA, les résultats sont-ils détachés ou gérés? Table comme structure de données java Un étrange avantage du support de transaction printanière pour l’annotation JPA + Hibernate + @ transactionnelle Java swt – Obtenir les coordonnées x, y réelles de l’image après la mise à l’échelle et le zoom Où sont compilés les fichiers Java JSP (* __ jsp.java)? FileInputStream ne fonctionne pas avec le chemin relatif Regroupement d’une application Java EE sans état avec Glassfish sur Amazon AWS Problème architectural avec l’environnement de cluster Tomcat Détection de collision pixel-parfait Android Comment forcer un disjoncteur Hyssortingx ouvert? Fichier de téléchargement Spring MVC – Statut HTTP 405 – La méthode de requête ‘POST’ n’est pas prise en charge. Modèle de visiteur Java au lieu d’instanceof switch Gson – Date imprévisible

Performance de Nashorn sur les JDK 9 et 10

Si vous interprétez la bibliothèque moment.js à l’aide de Nashorn sur JDK 8, celle-ci s’exécute en quelques secondes: 

 heure ... / JDK8 / bin / jjs moment-with-locales-2.22.2.js
 0m2.644s réel
 utilisateur 0m10.059s
 sys 0m0.287s

Mais faites la même chose sur les JDK 9 ou 10, et c’est terrible: 

 heure ... / JDK10 / bin / jjs moment-with-locales-2.22.2.js
 real 0m27.308s
 utilisateur 0m59.690s
 sys 0m1.353s

C’est littéralement dix fois plus lent. Est ce juste moi?

Je sais que Nashorn sera obsolète, mais ne devrait-il pas fonctionner correctement tant qu’il est pris en charge?

Aucune suggestion? Solutions de contournement?

Nashorn peut utiliser des «types optimistes» (voir plus bas), activés par défaut dans Java 9 et les versions ultérieures, mais entraînant des retards au démarrage.

Désactiver les types optimistes donne: 

$ time jjs --optimistic-types=false moment-with-locales.js real 0m4.282s user 0m0.000s sys 0m0.015s

Le commutateur peut être abrégé -ot=false .

jjs -h définit les types optimistes comme suit:

Utilisez des hypothèses de type optimistes avec une recompilation désoptimisée. Cela fait que le compilateur essaie, pour tout symbole de programme dont le type ne peut pas être prouvé lors de la compilation, de le taper aussi étroit et primitif que possible. Si le moteur d’exécution rencontre une erreur parce que le type de symbole est trop étroit, une méthode plus large sera générée jusqu’à ce que le niveau de stabilité soit atteint. Bien que cela produise le Bytecode Java le plus optimal possible, les suppositions erronées conduiront à un réchauffement plus long. La saisie optimiste est actuellement activée par défaut, mais peut être désactivée pour accélérer les performances de démarrage.

Ainsi, le typage optimiste peut générer des performances plus rapides à long terme (bien que cela ne soit pas garanti), mais entraîne un démarrage plus lent.