Et ben, c'est toujours pas clair et contradictoire. Si tu n'utilise pas de hot code replace, faudra que tu nous explique comment tu arrive à remplacer une classe sans relancer la JVM :aie:Citation:
Envoyé par SQUAL
Donc pour ce que j'ai compris,
:arrow: première option:
1) tu lance l'application (java -jar blablabla)
2) tu fais "nouveau jeu" ou autre
30 secondes
3) tu recommance "nouveau jeu"
2 secondes voir moins
4) tu quitte la JVM (retour au prompt)
5) tu modifie une classe
6) tu relance la JVM (a nouveau java -jar blablabla)
7) tu fais de nouveau "nouveau jeu" ou autre
30 secondes
Dans ce cas, je dirais que la différence entre le 30s et le 2 seconde viens d'un cache quelconque que tu as soit mis en place, soit qui a été mis en place à ton insu par une librairie que tu utilise. Donc
1) profiler les 30 secondes, si possible avec au moins deux profilers différents car ils ne sont jamais d'accord entre eux :)
2) identifer où tu passe le plus gros de tes 30 secondes
3) à partir de là essayer de l'optimiser
:arrow: deuxième option
1) tu lance l'application (java -jar blablabla)
2) tu fais "nouveau jeu" ou autre
30 secondes
3) tu quitte (retour au prompt) et tu relance le jeu (a nouveau java -jar blablabla)
2 secondes voir moins
4) tu quitte la JVM (retour au prompt)
5) tu modifie une classe
6) tu relance la JVM (a nouveau java -jar blablabla)
7) tu fais de nouveau "nouveau jeu" ou autre
30 secondes
Dans ce cas, la différence n'a certainement rien à voir avec java. Les optimisation faites par le JIT ne persistent pas d'un lancement à l'autre. Les deux raisons* que je pourrais voir sont
-> Des optimisation au niveau du cache disque de l'OS. LA première fois il lit tout sur le disque, la deuxième fois tout est déjà en mémoire cache, la troisième fois il faut de nouveau tout recharger parce que, ce qui se trouve en cache c'est maintenant le compilateur et toutes ses librairies dont on a eu besoin pour la compilation. Tu perd donc ton temps en IOs
-> Tu consomme énormément de mémoire. La première fois, l'OS "swape dehors" une partie de ton IDE en dehors de la mémoire vive pour faire de la place pour java. La deuxième fois, il y a une espace vide pile poil de la bonne taille puisqu'on a fermé l'application précédente qui l'occupait, donc pas d'opération de swapping. Ensuite tu retourne dans ton IDE, donc "swappe retour" depuis le disque vers la mémoire vive, compilation. Tu lance pour la troisième fois que tu lance, il faudra de nouveau swapper dehors une partie de l'IDE pour faire de la place pour ton application.
-> Même réflexion qu'au dessus, mais avec la mémoire graphique si ta carte a cette "merveilleuse" propriété de pouvoir utiliser de la RAM machine pour compenser un manque de RAM embarquée
* et visiblement je ne sais plus compter :aie:
