Bibliothèque de journalisation pour les jeux (c ++) [fermé]

15

Je connais beaucoup de bibliothèques de journalisation, mais je n'en ai pas testé beaucoup. (GoogleLog, Pantheios, le boost à venir :: bibliothèque de journaux ...)

Dans les jeux, en particulier dans les jeux multijoueurs et multithread à distance, la journalisation est vitale pour le débogage, même si vous supprimez tous les journaux à la fin.

Disons que je fais un jeu PC (pas une console) qui a besoin de journaux (multijoueur et multithread et / ou multiprocessus) et j'ai de bonnes raisons de chercher une bibliothèque pour la journalisation (comme, je n'ai pas le temps ou je suis pas confiant dans ma capacité à en écrire un correctement pour mon cas).

En supposant que j'ai besoin:

  1. performance
  2. facilité d'utilisation (autorisez le streaming ou le formatage ou quelque chose comme ça)
  3. fiable (ne fuit pas ou ne plante pas!)
  4. multiplateforme (au moins Windows, MacOSX, Linux / Ubuntu)

Quelle bibliothèque de journalisation recommanderiez-vous?

Actuellement, je pense que boost :: log est le plus flexible (vous pouvez même vous connecter à distance!), Mais n'a pas une bonne mise à jour des performances : est pour de hautes performances, mais n'est pas encore publié. Pantheios est souvent cité mais je n'ai pas de points de comparaison sur les performances et l'utilisation. J'ai utilisé ma propre librairie depuis longtemps mais je sais qu'elle ne gère pas le multithreading donc c'est un gros problème, même si c'est assez rapide. Google Log semble intéressant, j'ai juste besoin de le tester mais si vous avez déjà comparé ces bibliothèques et plus, vos conseils pourraient être utiles.

Les jeux sont souvent exigeants en termes de performances tout en étant complexes à déboguer.Il serait donc bon de connaître les bibliothèques de journalisation qui, dans notre cas spécifique, présentent des avantages évidents.

Klaim
la source
3
Une exigence importante que vous n'avez pas mentionnée est la raison pour laquelle vous avez l'intention d'utiliser les journaux. Les exigences pour la journalisation, par exemple, les messages de débogage, les métriques pour les concepteurs, l'état des caractères pour le support client et les transactions par carte de crédit, sont différentes. En général, vous compromis les performances, la facilité d'utilisation pour les programmeurs, la facilité / rapidité de l'analyse hors ligne et la durabilité en fonction de la situation.
C'est vrai, mais je supposais qu'une solution de journalisation "complète" permettrait aux utilisateurs de configurer différents types de journaux comme vous le décrivez. Si vous trouvez cette précision importante dans la question, soyez mon invité et ajoutez-le à la question.
Klaim

Réponses:

8

connectez-vous à l'aide de socket (n'importe quel wrapper de socket peut suffire) + navigateur web websocket => l'outil de journalisation le plus polyvalent et discret possible, gagnera des heures de débogage et évitera les yeux.

  • asynchrone (vitesse car il reporte tout le travail sur le navigateur)
  • formaté (couleur, taille etc.)
  • fiable (prises ...)
  • multiplateforme (navigateur)

Maintenant, le bonus:

  • filtrage dynamique très facile à faire (en utilisant le regex javascript si nécessaire)
  • avec historique des journaux, mémoire et comparaison (spécification HTML5 sur la base de données "dans le navigateur")
  • Un moyen facile de faire un graphique de toutes les données (en utilisant SVG, ou canvas ou quoi que ce soit) comme la mémoire , la fragmentation de la mémoire , etc ...
  • moyen facile de faire un graphique 2D de toutes les données ( subdivision d'arbre kd ? champ potentiel? ou même juste une variation de valeur variable? etc ...)
  • permet une journalisation à distance (en utilisant le navigateur d'un autre ordinateur)
  • en utilisant html5 dans le stockage du navigateur, vous pouvez stocker les paramètres de session de journal (filtres de journal actuels, etc. et même des notes sur chacun)
  • très facile de créer un rapport de bug ou de lier des tickets trac en un seul clic
  • possibilité de rembobiner la journalisation facilement, avec une interface chronologique

et bien d'autres tâches en dehors de la journalisation:

  • autorise les informations du profileur (graphiques ...)
  • peut même servir de console (envoyer une commande à partir du navigateur) ou même avec une interface graphique rapide en utilisant du HTML ou même une interface utilisateur flash
  • diff image dans le navigateur (envoyer l'image à l'aide de socket, et comparer dans le navigateur à l'aide des capacités de pixel d'image de canevas)
  • etc...

(presque tout ce qui précède peut être fait en utilisant des sockets flash, enregistrez les capacités de la base de données)

Maintenant, je sais que cela semble un peu long pour mettre en place la chose. Mais c'est vraiment un gain de temps sur un long projet, avec une situation de débogage difficile (comme dans les jeux.) C'est la chose la plus puissante que j'ai utilisée depuis les débogueurs ...

Remarque 1: le seul inconvénient => double effet secondaire lors du débogage du code de mise en réseau du jeu (impact sur la taille du buffer de socket, la latence, la bande passante, etc ...)

Remarque 2: certains navigateurs désactivés par la prise Web par défaut pour des raisons de sécurité, vérifiez: configurez les choses pour vous assurer qu'elles sont activées.

Tuan Kuranes
la source
1
Corrigez-moi si je me trompe, mais cela suggère seulement où diriger la sortie de journalisation, non? Une véritable bibliothèque de journalisation permettrait également de filtrer au moment de la compilation (ce qui est crucial si les performances sont un problème), de formater et de fournir une syntaxe facile à utiliser pour créer des messages de journal.
sbi
@sbi C'est une chose globale on ou off du côté application. "Browser log client" fait le filtrage, la syntaxe, mais il obtient toujours tout le journal. C'est radical, mais c'est basé sur l'expérience que pendant le développement, vous devez toujours tout enregistrer afin de pouvoir attraper / reproduire facilement tous les bugs que vous rencontrez. Si vous devez optimiser, c'est à nouveau du côté du navigateur: en utilisant socket, vous n'êtes pas obligé de vous connecter en utilisant une chaîne, vous pouvez directement enregistrer des données binaires (Id + floats), qui sont en gras plus rapidement que toute autre bibliothèque de journaux basée sur une chaîne ... ( identifiant correspondant au côté du navigateur de chaînes ...)
Tuan Kuranes
1
Bien que je puisse voir que c'est très pratique, c'est vraiment juste le backend d'un enregistreur (ce que Templog appelle un "log sink", IIRC). La performance est l'une des exigences énumérées. J'ai trouvé que je dois ajouter des instructions de journal à un morceau de code pendant le débogage, mais une fois qu'il est opérationnel, ce morceau de code serait trop bavard et noyerait tout ce sur quoi je travaille alors dans son bruit, et coûterait également trop de performances. Je veux donc pouvoir augmenter et diminuer le niveau de journalisation sur des morceaux entiers de code en changeant quelques lignes de code. C'est ce que la couche intermédiaire d'une librairie fait pour vous.
sbi
@sbi: peut nécessiter des références, mais il est possible que la meilleure bibliothèque de journalisation, même au niveau de journalisation le plus bas, vous coûte toujours plus cher qu'un enregistreur binaire qui enregistre tout. Il n'y a même pas un seul cycle CPU "binaire à caractère" perdu ... C'est donc vraiment plus de fonctionnalités ET plus de performances.
Tuan Kuranes
Avant de décider d'utiliser réellement templog, nous avons fait quelques tests. Si la journalisation est désactivée pour la gravité, l'origine ou autre d'un message de journal spécifique, et si le compilateur est en mesure de découvrir qu'il n'y a pas d'effets secondaires lors de l'évaluation des paramètres, VC est en effet en mesure d'optimiser un message complet enregistrer la déclaration dans le néant. Et en ce qui concerne la vitesse, vous ne battrez pas le code qui n'est pas là pour être exécuté en premier lieu.
sbi
8

En ce qui concerne les performances, j'ai trouvé templog à peu près invaincu. Il utilise des modèles d'expression pour différer l'évaluation des instructions de journalisation jusqu'à ce qu'il soit établi que les informations seront enregistrées. Comme vous pouvez également désactiver partiellement la journalisation (en fonction de la gravité, de l'origine et de l'audience cible d'un message de journal), certaines de ces instructions de journalisation peuvent être éliminées à zéro code par le compilateur pour les versions. (J'ai effectivement vu cela se produire avec VC.)

Il n'y a pas eu grand-chose à faire à la bibliothèque récemment, et d'autres sur SO ont trouvé le coffre manquant à certains égards, mais dans une entreprise pour laquelle je travaillais, nous avons trouvé le gars assez réactif, et l'un de mes vaches à l'époque était même a obtenu un accès de validation et y a ajouté du code, vous pourriez donc le trouver utile.

Pour énumérer vos besoins:

performance

Le meilleur que j'ai trouvé. En particulier, sa capacité à exclure les messages de journal au moment de la compilation et à ce que le compilateur les élimine complètement était très attrayante.

facilité d'utilisation (autorisez le streaming ou le formatage ou quelque chose comme ça)

Il y a les horribles messages d'erreur classiques du compilateur de trucs meta-meta lorsque vous faites quelque chose de mal, mais quand il s'agit de facilité d'utilisation, cela

TEMPLOG_LOG(my_logger,sev_error,aud_support) << "logged in as " << user_name;

est difficile à battre.
Cependant, vous devrez peut-être créer vos propres récepteurs de journaux (c'est là que les messages de journal vont), car les quelques pré-emballés (stderr, fichier, journalisation Windows, etc.) ne sont pas si sophistiqués. En raison de la performance étant un objectif principal, les éléments intrinsèques de l'ensemble sont quelque peu compliqués (comme les formateurs de messages de journal étant assez emmêlés avec les récepteurs de journaux), mais nous l'avons maîtrisé (je me souviens l'avoir traversé dans un débogueur pour y aider) et une fois compris qu'il n'était pas si difficile d'écrire vos propres formateurs de messages ou vos journaux.

fiable (ne fuit pas ou ne plante pas!)

Nous l'avons utilisé sans trouver de tels problèmes graves. Il n'y a pratiquement aucune allocation de mémoire dynamique, il est donc difficile d'imaginer même qu'il fasse quelque chose de mal. Bien sûr, nous ne l'avons testé que dans des conditions réelles dans un seul produit.

multiplateforme (au moins Windows, MacOSX, Linux / Ubuntu)

Lorsque nous l'avons utilisé, nous l'avons utilisé sur Win32, OSX et plusieurs distributions Linux différentes, dont Ubuntu.

En ce qui concerne le multi-threading: nous ne l'avons pas utilisé, mais d'après ce que je me souviens de l'architecture de la lib, il semble que vous n'auriez besoin de gérer cela que dans les récepteurs de journaux. ICBWT.

sbi
la source
Merci, je ne connaissais pas celui-ci. Cela ressemble à une version simplifiée (et performante) de boost :: log, au moins dans l'idée originale.
Klaim
@Klaim: Je ne pense pas que boost avait quoi que ce soit à offrir la dernière fois que j'ai examiné les bibliothèques de journalisation C ++, donc je ne connais pas boost :: log.
sbi
1
@Joe: Comprenez-vous le terme "modèles d'expression" ??
sbi
1
Je pensais que je l'avais fait, mais maintenant j'ai téléchargé et commencé à lire le code source de templog, et il semble que C ++ m'a encore surpassé.
1
@sbi: Une partie de ma confusion était votre déclaration "passée à la fois à travers plusieurs couches" - En anglais à la fois peut signifier immédiatement ou ensemble , qui dans ce cas sont opposés. Je l'ai lu comme le premier, et vous (maintenant évidemment pour moi) vouliez dire le second. Merci d'avoir pris le temps de l'expliquer.
0

Vous pourriez être intéressé par l' ensemble d' outils baical :

  • Bibliothèque open source et multiplateforme (Win, Linux, x86 / x64) pour les journaux, les traces et la télémétrie - P7
  • Incroyablement rapide (conçu pour les appareils intégrés) - 3 millions de journaux par seconde sur le réseau, 5 millions à archiver sur un processeur moderne. Je ne connais aucune autre bibliothèque de journalisation qui fournisse une telle vitesse et des informations si détaillées pour chaque message de journal.
  • Thread safe
  • Chaque message de trace contient:
    • message texte
    • niveau
    • heure précise (100ns)
    • fichier source, nom et ligne de la fonction
    • ID et nom du module
    • ID de thread et nom de thread
    • indice du cœur du processeur
  • Application serveur pour recevoir et afficher les journaux et la télémétrie
  • Vous pouvez collecter, analyser, rechercher, filtrer les journaux de plusieurs sources en temps réel
maximu
la source
À partir de 06/2017% s, le formatage des chaînes n'est pas encore pris en charge.
Romeno