Posté par YBoy360 (site web personnel) .
Évalué à 3 (+1/-0).
Dernière modification le 31 mai 2025 à 21:46.
Ce serait intéressant de tester avec les options -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders de Java 24. Surtout la consommation mémoire…
Avec les options ci-dessus, j'obtiens des gains de l'ordre de 20 à 30 %.
Sinon, concernant GraalVM, c'est impressionnant l'amélioration coté consommation mémoire (divisé par 3), mais les performances ne sont pas aussi bonne qu'avec Java 24 et les options par défaut.
J’ai mis les détails ici. Mon ressenti, c’est surtout que ça ne va pas tellement jouer au niveau du framework (ce qui est testé ici) mais plutôt sur de vraies applications avec des vraies quantités de code et de données.
Sur une application existante, il vaut mieux optimiser l'existant en réduisant le nombre de dépendances, en tunant la jvm, en générant un jdk light si on déploie dans des conteneurs…
Changer de cadriciel est rarement une stratégie gagnante, car ça revient souvent à réécrire l'application.
Si vraiment on part sur une réécriture, autant changer carrément de langage. J'avais espoir il y a quelques années que la jvm et les cadriciels java fassent un régime, mais quand je vois les consommations mémoires du moindre hello world web, je me dis qu'on est juste sur un québecois qui arrête le supplément fromage avec sa poutine.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Si vraiment on part sur une réécriture, autant changer carrément de langage.
C’est une possibilité encore plus rare que de pouvoir refondre l’application en profondeur, parce que ça implique :
Soit d’avoir une équipe technique qui maitrise raisonnablement un nouveau langage qui soit plus performant que la JVM (et mine de rien ça réduit les choix) ;
Soit d’accepter de perdre une grande partie de la connaissance métier en changeant l’équipe de développement au passage.
Dans les deux cas ça mène à des risques forts et réels de nouveau projet qui se vautre parce que codé n’importe comment.
D’ailleurs mon expérience (et ça n’est que ça) c’est que sur un projet du type dont je parle ici (gros monolithe) qui tourne sur la JVM, c’est rarement le langage et l’environnement d’exécution qui sont le facteur limitant. Aujourd’hui les JVM sont performantes pour le côté calculatoire, et l’occupation mémoire est plutôt un problème quand on doit lancer des dizaines de JVM en parallèle (typiquement pour une architecture micro-services), car ça implique d’avoir des dizaines de fois l’overhead de la JVM et dégrade le rapport entre mémoire « utile » de travail et mémoire « technique ».
Par contre, ce que j’ai très souvent constaté, c’est du code très inefficace parce que codé n’importe comment, qui se retrouve avec au moins l’un de ces problèmes :
Les personnes qui l’ont développé ne connaissaient rien au langage et aux outils et ont fait n’importe quoi avec (exemple : remonter toute une table en Java pour faire un filtre avec Java au lieu de faire une requête). Très présent si le code a été outsourcé sans contrôle très strict…
Croyance que « JVM = garbage collector = mémoire magique », le code se retrouve pourri de fuites mémoires (souvent ça va avec une mauvaise architecture).
Architecture du code absurdement complexe qui empile les couches de « services » et de « factories » jusqu’à l’infini, ce qui impose de créer des centaines d’objets pour la moindre opération, sans garantie que les fonctionnalités soient bien isolées. Spécialité de gros frameworks de très grosses entreprises, oui c’est à toi que je pense IBM.
Dans ce cas un truc qui, d’expérience, fonctionne bien c’est de reprendre un projet sur une base propre, avec une architecture propre, quitte à copier les éléments (en particulier le code métier) qui fonctionnent du le projet d’origine.
Déjà, merci d'avoir jeté un oeil à Quarkus. Ca fait plaisir d'en entendre parler par ici :). J'avais hésité plusieurs fois à faire un journal, il me semble que j'avais même commencé à en rédiger un et puis c'est tombé dans l'oubli.
Ensuite, même si Quarkus a été marketé pour les micro-services au départ, tu peux parfaitement construire des bonnes grosses applications. Personnellement, je suis un fervent défenseur du cas d'usage de la "boring app", la bonne vieille application de gestion toute bête qui fait le taf.
Après, je te concède que cette limite est pénible, je jetterai un oeil à ton générateur, merci de l'avoir partagé. Je sais qu'on a une limite côté ArC qui peut poser souci au niveau du nombre de classes qui sont des beans CDI. On en a parlé plusieurs fois, je pense qu'il faut qu'on travaille pour la lever.
Ca ne concerne pas tant d'applications que ça, mais j'aimerais autant qu'on soit aussi généraliste que possible. Avoir des limites arbitraires, même élevées, c'est relou.
Pour la compilation native, oui, ça demande des ressources assez élevées si l'application est grosse au point de devenir assez inutilisable. Ce n'est pas un cas d'usage où je conseillerais la compilation native.
Je ferais un peu de profiling de la phase de construction avec ton exemple parce que ça me semble assez intéressant de regarder s'il y a des endroits où on peut réduire le temps de construction de l'application. Merci d'avoir partagé le générateur et merci de le laisser où il est, ça va nous être utile :).
Si jamais tu veux échanger plus avant, je suis joignable à guillaume point smet à gmail point com et je suis toujours ravi d'échanger sur le sujet.
# Java 24
Posté par YBoy360 (site web personnel) . Évalué à 3 (+1/-0). Dernière modification le 31 mai 2025 à 21:46.
Ce serait intéressant de tester avec les options
-XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeadersde Java 24. Surtout la consommation mémoire…Avec les options ci-dessus, j'obtiens des gains de l'ordre de 20 à 30 %.
Sinon, concernant GraalVM, c'est impressionnant l'amélioration coté consommation mémoire (divisé par 3), mais les performances ne sont pas aussi bonne qu'avec Java 24 et les options par défaut.
[^] # Re: Java 24
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
J’ai mis les détails ici. Mon ressenti, c’est surtout que ça ne va pas tellement jouer au niveau du framework (ce qui est testé ici) mais plutôt sur de vraies applications avec des vraies quantités de code et de données.
La connaissance libre : https://zestedesavoir.com
# Ecoconception
Posté par devnewton 🍺 (site web personnel) . Évalué à 6 (+3/-0).
Sur une application existante, il vaut mieux optimiser l'existant en réduisant le nombre de dépendances, en tunant la jvm, en générant un jdk light si on déploie dans des conteneurs…
Changer de cadriciel est rarement une stratégie gagnante, car ça revient souvent à réécrire l'application.
Si vraiment on part sur une réécriture, autant changer carrément de langage. J'avais espoir il y a quelques années que la jvm et les cadriciels java fassent un régime, mais quand je vois les consommations mémoires du moindre hello world web, je me dis qu'on est juste sur un québecois qui arrête le supplément fromage avec sa poutine.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Ecoconception
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 4 (+2/-0).
C’est une possibilité encore plus rare que de pouvoir refondre l’application en profondeur, parce que ça implique :
Dans les deux cas ça mène à des risques forts et réels de nouveau projet qui se vautre parce que codé n’importe comment.
D’ailleurs mon expérience (et ça n’est que ça) c’est que sur un projet du type dont je parle ici (gros monolithe) qui tourne sur la JVM, c’est rarement le langage et l’environnement d’exécution qui sont le facteur limitant. Aujourd’hui les JVM sont performantes pour le côté calculatoire, et l’occupation mémoire est plutôt un problème quand on doit lancer des dizaines de JVM en parallèle (typiquement pour une architecture micro-services), car ça implique d’avoir des dizaines de fois l’overhead de la JVM et dégrade le rapport entre mémoire « utile » de travail et mémoire « technique ».
Par contre, ce que j’ai très souvent constaté, c’est du code très inefficace parce que codé n’importe comment, qui se retrouve avec au moins l’un de ces problèmes :
Dans ce cas un truc qui, d’expérience, fonctionne bien c’est de reprendre un projet sur une base propre, avec une architecture propre, quitte à copier les éléments (en particulier le code métier) qui fonctionnent du le projet d’origine.
La connaissance libre : https://zestedesavoir.com
# Merci !
Posté par Guillaume Smet (site web personnel) . Évalué à 5 (+4/-0).
Hello,
Déjà, merci d'avoir jeté un oeil à Quarkus. Ca fait plaisir d'en entendre parler par ici :). J'avais hésité plusieurs fois à faire un journal, il me semble que j'avais même commencé à en rédiger un et puis c'est tombé dans l'oubli.
Ensuite, même si Quarkus a été marketé pour les micro-services au départ, tu peux parfaitement construire des bonnes grosses applications. Personnellement, je suis un fervent défenseur du cas d'usage de la "boring app", la bonne vieille application de gestion toute bête qui fait le taf.
Après, je te concède que cette limite est pénible, je jetterai un oeil à ton générateur, merci de l'avoir partagé. Je sais qu'on a une limite côté ArC qui peut poser souci au niveau du nombre de classes qui sont des beans CDI. On en a parlé plusieurs fois, je pense qu'il faut qu'on travaille pour la lever.
Ca ne concerne pas tant d'applications que ça, mais j'aimerais autant qu'on soit aussi généraliste que possible. Avoir des limites arbitraires, même élevées, c'est relou.
Pour la compilation native, oui, ça demande des ressources assez élevées si l'application est grosse au point de devenir assez inutilisable. Ce n'est pas un cas d'usage où je conseillerais la compilation native.
Je ferais un peu de profiling de la phase de construction avec ton exemple parce que ça me semble assez intéressant de regarder s'il y a des endroits où on peut réduire le temps de construction de l'application. Merci d'avoir partagé le générateur et merci de le laisser où il est, ça va nous être utile :).
Si jamais tu veux échanger plus avant, je suis joignable à guillaume point smet à gmail point com et je suis toujours ravi d'échanger sur le sujet.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.