Discussion :

[tchize_]

A tchize_ :
- J'utilise une seule JVM, et je fais le test en lancant le jeu deux fois de suite (hors Eclipse), la la difference se voit. Ma remarque sur le developpement en eclipse portait sur le fait qu'en modifiant une classe (pas de hot code replace), la lenteur réapparaissait.

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

Donc pour ce que j'ai compris,

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


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

[SQUAL]

Salut tchize,

merci pour ta (si longue) réponse, je pense que tu es celui qui a le mieux cerné mon problème et je t'en remercie. Je n'ai pas encore eu le temps de profiler la partie sensible. Dés que je le 'aurais fait, je reviendrais t'embêter encore sur cette histoire de cache disque. Si jamais tu arrives à m'aider à résoudre mon souci, je peux t'assurer que je mettrais ton nom au générique de fin du jeu