Automatiser les tests de performances XNA?

Je me demandais quelles étaient les approches ou les opinions des gens sur l'automatisation des tests de performances dans XNA. Actuellement, je ne travaille que dans 2d, mais cela pose de nombreux domaines où les performances peuvent être améliorées avec différentes implémentations.

Un exemple serait si vous aviez 2 implémentations différentes de partitionnement spatial, l'une peut être plus rapide que l'autre mais sans faire de test de performance réel, vous ne pourriez pas dire laquelle avec certitude (sauf si vous avez vu que le code était manifestement lent dans certains les pièces). Vous pouvez écrire un test unitaire qui, pendant un laps de temps donné, a continué à ajouter / mettre à jour / supprimer des entités pour les deux implémentations et à voir combien ont été effectuées dans chaque période et la plus élevée serait la plus rapide (dans cet exemple donné).

Un autre exemple de niveau supérieur serait si vous vouliez voir combien d'entités vous pouvez avoir à l'écran à peu près sans descendre en dessous de 60fps. Le problème avec cela est que pour l'automatiser, vous devrez utiliser l'astuce de forme cachée ou une autre chose pour lancer un jeu simulé et tester uniquement les parties qui vous intéressent et désactiver tout le reste.

Je sais que ce n'est pas une affaire simple, car même si vous pouvez automatiser les tests, il appartient vraiment à un humain d'interpréter si les résultats sont suffisamment performants, mais dans le cadre d'une étape de construction, vous pouvez le faire exécuter ces tests et publier les résultats quelque part pour comparaison.

De cette façon, si vous passez de la version 1.1 à 1.2 mais que vous avez modifié quelques algorithmes sous-jacents, vous remarquerez peut-être qu'en général, le score de performance aurait augmenté, ce qui signifie que vous avez amélioré vos performances globales de l'application, puis de 1.2 à 1.3, vous remarquerez peut-être que vous avez ensuite un peu baissé les performances globales.

Est-ce que quelqu'un a automatisé ce genre de chose dans ses projets, et si oui, comment mesurez-vous vos comparaisons de performances à un niveau élevé et quels cadres utilisez-vous pour tester? En fournissant que vous avez écrit votre code afin qu'il soit testable / mockable pour la plupart des parties, vous pouvez simplement utiliser vos tests comme mécanisme pour obtenir des résultats de performance ...

=== Modifier ===

Pour plus de clarté, je suis plus intéressé par la meilleure façon d'utiliser des tests automatisés au sein de XNA pour suivre vos performances, pas de jouer à des tests ou de deviner en exécutant manuellement votre jeu sur une machine. Cela est complètement différent de voir si votre jeu est jouable sur du matériel X, il s'agit davantage de suivre le changement de performances à mesure que votre moteur de jeu / framework change.

Comme mentionné dans l'un des commentaires, vous pouvez facilement tester "combien de nœuds puis-je insérer / supprimer / mettre à jour dans QuadTreeA en 2 secondes", mais vous devez regarder physiquement ces résultats à chaque fois pour voir s'il a changé, ce qui peut être très bien et c'est toujours mieux que de simplement compter sur le jouer pour voir si vous remarquez une différence entre les versions. Cependant, si vous deviez mettre un Assert pour vous informer d'un échec s'il est inférieur à 5000 disons en 2 secondes, vous avez un test fragile car il est alors contextuel au matériel, pas seulement à l'implémentation. Bien que cela étant dit, ce type de tests automatisés n'est vraiment utile que si vous exécutez vos tests comme une sorte de pipeline de construction, c'est-à-dire:

Paiement -> Exécuter les tests unitaires -> Exécuter les tests d'intégration -> Exécuter les tests de performances -> Package

Ainsi, vous pouvez facilement comparer les statistiques d'une génération à une autre sur le serveur CI sous la forme d'un rapport quelconque, et encore une fois, cela peut ne pas signifier grand-chose pour personne si vous n'êtes pas habitué à l'intégration continue. Le nœud principal de cette question est de voir comment les gens gèrent cela entre les builds et comment ils trouvent le meilleur rapport. Comme je l'ai dit, cela peut être subjectif, mais comme les connaissances seront acquises à partir des réponses, cela semble une question valable.

Je suppose que vous voulez complètement exclure "Exécuter le jeu réel", donc fondamentalement ma réponse est disqualifiée dès le départ. Mais peut-être que vous pouvez en retirer quelque chose , d'où la raison pour laquelle je poste ceci:

Pour ma thèse de maîtrise, j'ai plusieurs implémentations indépendantes / parallèles pour réaliser la même chose pour certains modules de mon moteur de jeu et j'ai besoin de réaliser quelques mesures de performances. Techniquement, rien ne m'empêcherait de simplement lancer le jeu et de regarder les chiffres affichés dans le profileur à l'écran, mais je voulais toujours automatiser cela parce que c'est un processus fastidieux à effectuer chaque fois que mon implémentation change.

Donc, ce que j'ai, c'est ceci:

• Un profileur de portée (qui place un objet sur la pile, prend un horodatage lors de la construction et un lors de la déconstruction) qui est utilisé pour mesurer le temps nécessaire à l'exécution de la fonction / étendue d'intérêt.
• Un module qui stocke un certain nombre d'échantillons profilés et transfère la moyenne des n derniers échantillons dans un fichier texte simple
• Une ligne de commande dans le jeu qui peut être utilisée pour démarrer un jeu, charger une carte, changer l'algorithme utilisé dans le module à inspecter, changer le chemin du fichier de vidage du profileur et beaucoup d'autres choses. Ladite ligne de commande est configurée pour vérifier un certain fichier spécial dans le répertoire exécutable et le charger pour exécuter la chaîne récupérée à partir de lui (comme moyen de communication inter-processus très, très grossière)

Donc, cela me permet de lancer mon application à partir de n'importe quel environnement de script à moitié décent (par exemple, l'invite de commande Windows via des scripts batch - mais j'utilise en fait Ruby à cette fin), définir un chemin de fichier de vidage, charger une carte, le laisser en cours d'exécution pendant quelques minutes, quittez le jeu en cours d'exécution, définissez un autre chemin de fichier de vidage, changez l'algorithme à utiliser, chargez à nouveau la carte, rincez, répétez. Le script Ruby communique avec le jeu en vol en créant ce fichier spécial que le module de ligne de commande recherche et en mettant les commandes souhaitées dans la syntaxe que la ligne de commande comprend.

Je n'ai pas réellement utilisé l'intégration continue sur ce projet pour le moment, mais rien ne m'empêcherait de gonfler ce script Ruby pour analyser également les journaux de performances générés et produire du XML compatible xUnit pour communiquer avec le système CI lorsque les performances se sont inopinément allé détraqué pour une raison quelconque et exécuter le script sur chaque build complet sur le serveur de build.

D'accord, donc mon jeu n'est pas écrit en XNA (c'est du C ++ et DirectX), et cette approche ne respecte pas le fait que vous ne voulez pas réellement exécuter le jeu sur votre serveur de build. Il est également loin d'être aussi flexible que ce que vous recherchez probablement - mais tout de même, c'est une approche soignée et à faible technologie pour la mesure automatisée des performances qui est quelque peu compatible avec les CI (à condition que l'on ait un serveur de construction costaud).

Edit: Quant à savoir jusqu'où j'ai réellement pris cette approche - je ne compare que les mesures de performances obtenues à partir de différentes implémentations de ce seul module. Mais l'ensemble du système est configuré de manière à me permettre de vider n'importe laquelle des catégories définies pour mon cadre de profilage léger et d'utiliser l'environnement de script externe pour interpréter les résultats de la manière qui semble utile immédiatement. En retirant l'aspect profilage des performances de l'équation, j'ai également l'intention de

• Vérifiez la validité / cohérence de tous les actifs en chargeant toutes les cartes contenant tous les modèles / textures / sons et en vérifiant les journaux du moteur pour tout ce qui est inhabituel
• tester le moteur et surveiller les journaux pour tout comportement inattendu de cette façon sur une période de plusieurs heures / jours

Je ne vois pas ce que vous décrivez comme un outil utile. En tant que développeur, un simple indice de performance est presque inutile.

Ce que vous voulez est de profiler votre code, de le diviser en morceaux logiques et de mesurer combien de temps chacun utilise, pointe et moyenne. Vous pouvez maintenant savoir quelle partie du code cause des problèmes et vous savez où chercher les optimisations.

La partie délicate n'est pas les changements de performances d'une génération à l'autre, vous n'avez pas besoin d'un automatisé pour le comprendre. La partie délicate est les différences de performances entre les différentes machines, il n'y a aucun moyen d'extrapoler les performances d'une machine à une autre avec une carte vidéo différente, etc.

Donc, ce que vous voulez, c'est une fonctionnalité de référence afin que vous puissiez faire une course en un clic et obtenir les numéros de profilage. De cette façon, vous pourrez tester plusieurs machines simultanément. Il existe plusieurs façons de le faire, par exemple, vous pouvez remplacer l'entrée utilisateur pour vous rapprocher le plus possible de l'exécution d'une session de jeu normale.

Vous pouvez également souhaiter avoir un test plus long afin de détecter les fuites de mémoire.