6. Performances générales de l'API Senior 2.0
Les performances générales d'un tel moteur sont assez difficiles à évaluer, et ce pour plusieurs raisons:
des tests sur différents types de jeu auraient été nécessaires pour avoir des résultats moyens qui pourraient se rapprocher de la réalité.
Le jeu réalisé occupe une bonne partie du temps machine, du fait des formules géométriques appliquées intensivement tout au long d'une partie.
Le principe même du billard rend l'appréhension du calcul relativement difficile à évaluer, car l'algorithme de détection de collision engouffre lui aussi une bonne partie des ressources machine. De plus, la complexité de cet algorithme étant en O(n²), tout ajout de balle dans le billard fini par greffer de manière importante les ressources disponibles.
L'analyse des performances n'a donc pas été réalisée par technique de profiling. Les tests se sont bornés à certaines optimisations plus faciles à contrôler.
Le jeu a été compilé en optimisation élevée, sans vérification de type (option -unsafe du compilateur Bigloo), avec une arithmétique non-émulée (opérateurs +fl, -fl, *fl, etc...). Ces optimisations représentent des conditions tout a fait réaliste de test car un jeu écrit dans un langage plus commun comme le C aurait été compilé avec des conditions générales d'optimisation similaires.
De même, pour éviter de faire saturer OpenGL avec des calculs trop intenses, nous avons remplacé les boules par des cubes.
 | Le remplacement des boules par des cubes a bien entendu été réalisé seulement pour rendre plus pertinents les résultats de la phase de test de la machine réactive. Le jeu final tourne évidemment avec des boules ! |
Le temps de calcul libéré pour le processeur est énorme, puisqu'une "vrai" boule, qui à l'origine faisait 168 triangles, n'en fait plus que 12 une fois transformée en cube. De même le rendu de texture et le calcul de lumière à été enlevé. Cela permet de se mettre dans des conditions optimales (au niveau de la 3D) pour essayer d'évaluer les performances de Senior.
Le déroulement normal du jeu de billard fait évoluer seize boules. Senior s'en sort plutôt bien , puisqu'il faut attendre pas moins de 68 cubes pour apercevoir un ralentissement. avec 120 cubes, le jeu reste tout a fait jouable, bien que les ralentissements commencent à se faire ressentir.
Dans l'ensemble, les coût de Senior ne semble pas très important. Les performances du jeu ne s'écroulent pas avant de remplir entièrement de boules la surface du jeu. On peut souligner que l'implémentation actuelle de Senior n'utilise pas le mécanisme de postage d'événement le plus avancé: une implémentation de Junior en Java a déjà été développé avec des mécanismes plus complexes donnant de meilleurs résultat. Cela aurait sûrement pus faire chuter encore un peu le surcoût déjà très faible de Senior, puisque l'algorithme de collision, se base fondamentalement sur le mécanisme de diffusion de messages.