Après investigation, effectivement à chaque partie 30 Mo sur les 33 Mo qu'alloue notre app sont leakés. Si on joue longtemps on leake 30 Mo de plus par 3 minutes. Le javascript est un langage garbage collecté hein, donc aucun problème non ? Pourquoi s'emmerder. Ben la réalité c'est que ni le moteur qu'on utilise (PlayCanvas) ni notre code ne suit aucun des principes de base de gestion de la mémoire, comme par exemple se poser la question "à qui 'appartient' cet objet, quel est son cycle de vie ? avec qui peut-il interagir, qu'est-ce qu'il se passe avec les informations qui transitent, combien de temps est valide l'état", etc. et donc ouais pas de miracle, tout est leaké avec des références cycliques que Javascript peut pas nettoyer. Concrètement, Javascript est capable de nettoyer les références cycliques car il a un vrai GC, mais il ne peut pas dès qu'il existe une closure référençant un des objets dans le cycle, et en codant en JS typique c'est facile d'avoir aussi des cycles entre ces closures. Bref au final il a fallu revenir au memory management à la C++. Ca n'a peut être pas pris autant de temps, mais ça reste super fragile (il faudrait à minima des tests unitaires pour les memory leaks, et aucun CI ne semble à priori proposer ça). Et quoi qu'il en soit PlayCanvas n'offre juste aucun moyen de nettoyer et on leake un minimum d'1.5 Mo à chaque partie (mais c'est vraiment un minimum, en allant taper dans les variables internes du moteur pour lui forcer à libérer des choses qu'il ne devrait pas garder). Donc oui le Javascript c'est facile à coder, à peu près comme du C++ où tu ne ferais que des new et jamais de delete (essayez, c'est tout à coup surprenamment facile le C++ !), et justement ça tombe bien le résultat est le même en consommation de ressource
A savoir d'ailleurs, c'est pour ça que JS ne fonctionne réellement que dans un contexte serveur, avec des workers (processus) démarrés dynamiquement et terminant avec leur tâche. Pour tout le reste, tout soft JS est amené à planter sur la durée.