| 📰 Title: | Tracy Profiler | 🕹️ / 🛠️ Type: | Tool |
|---|---|---|---|
| 🗃️ Genre: | Development | 👁️ Visual: | 2D |
| 🏷️ Category: | Development ➤ Debug | 🏝️ Perspective: | First person (interface) |
| 🔖 Tags: | Development; Debug; Performance analysis | ⏱️ Pacing: | Real Time |
| 🐣️ Approx. start: | 2017-09-10 | 👫️ Played: | Single |
| 🐓️ Latest: | 2024-08-22 | 🚦 Status: | 04. Released (status) |
| 📍️ Version: | Latest: 💥️ 0.11.1 / Dev: 5d542dc | ❤️ Like it: | 9. ⏳️ |
| 🏛️ License type: | 🕊️ Libre | 🎀️ Quality: | 7. ⏳️ |
| 🏛️ License: | BSD 3-Clause | ✨️ (temporary): | |
| 🐛️ Created: | 2023-10-20 | 🐜️ Updated: | 2024-09-09 |
| 📦️ Package name: | tracy | ..... 📦️ Arch: |  |
|---|---|---|---|
| 📄️ Source: | |
..... 📦️ RPM: | |
| ⚙️ Generic binary: | ..... 📦️ Deb: | ||
| 🌍️ Browser version: | ..... 📦️ AppImage: | ||
| 📱️ PDA support: | ..... 📦️ Flatpak: | ||
| ✨️ Not use: | ..... 📦️ Snap: |
| 📰 What's new?: | 👻️ Temporary: | ||
|---|---|---|---|
| 💡 Lights on: | 🎨️ Significant improvement: | ||
| 👔️ Already shown: | 💭️ New version published (to be updated): | ||
| 🎖️ This work: |  |
🚧️ Some work remains to be done: | |
| 👫️ Contrib.: | goupildb | 🦺️ Work in progress: | |
| 🎰️ ID: | 16360 |
| 📜️[en]: | A libre, multi-platform real-time profiler for game development, with nanosecond resolution, remote telemetry, hybrid pre-sampling and framing. By integrating calls to the library in the source code of an application, developers can measure the performance of their code and detect sources of slowdown, with a view to optimizing speed and fluidity. It supports CPU and GPU profiling, memory allocation, locks, context switching, automatic assignment of screenshots to captured images, and much more. | 📜️[fr]: | Un profileur temps réel libre et multi-plateforme pour le développement de jeux, avec une résolution de l'ordre de la nanoseconde, une télémétrie à distance, un pré-échantillonnage et une trame hybrides. En intégrant les appels à la bibliothèque dans le code source d'une application, les développeurs peuvent mesurer la performance de leur code et détecter les sources de ralentissement, en vue d'optimiser la rapidité et la fluidité. Il prend en charge le profilage du CPU, GPU, les allocations de mémoire, les verrous, les changements de contexte, l'attribution automatique de captures d'écran aux images capturées, et bien d'autres choses encore. |
|---|
🦝️ From Users: (0.2/201803), (202309),
💎 Features: 💥️(202304),
🕯️ How To: (202203),
🏡️ Website & videos
[Homepage] [Dev site] [Features/About] [Screenshots] [Videos ft(202304) pv(0.8/202203) pv(0.7/202006) t(202xxx) gd(202xxx) gu(0.2/201803) gu(202309) gu[de](202101) r(202xxx) lp(202xxx) ht(202203) ht[fr](202xxx) ht[de](202xxx) ht[ru](202xxx) ht[pl](202xxx) ht[cz](202xxx) ht[sp](202xxx) ht[pt](202xxx) ht[it](202xxx) ht[tr](202xxx)] [WIKI(direct link to a PDF file)] [FAQ] [RSS] [Changelog 1 2 3]
💰 Commercial
• (empty)
🍩️ Resources
• Interactive demo (demo): [Homepage]
🛠️ Technical informations
[PCGamingWiki] [MobyGames]
🦣️ Social
Devs (Tracy Profiler Team 1 2 [fr] [en]): [Site 1 2] [Chat] [mastodon] [PeerTube] [YouTube] [PressKit] [Interview 1(202xxx) 2(202xxx)]
The Project: [Blog] [Chat] [Forums] [mastodon] [PeerTube] [YouTube] [PressKit] [Lemmy] [reddit] [Discord]
🐝️ Related
📦️ Misc. repositories
[Repology] [pkgs.org] [Generic binary] [Arch Linux / AUR] [openSUSE] [Debian/Ubuntu] [Flatpak] [AppImage(author's repo)] [Snap] [PortableLinuxGames]
🕵️ Reviews
[HowLongToBeat] [metacritic] [OpenCritic] [iGDB]
🕊️ Source of this Entry: [GameFromScratch about Comfy engine (20231019)]
🦣️ Social Networking Update (on mastodon)
🛠️ Title: Tracy Profiler
🦊️ What's: A libre real-time profiler for game development
🏡️ -
🐣️ https://github.com/wolfpld/tracy
🔖 #LinuxGameDev #Programming #Debug #PerformanceAnalysis
📦️ #Libre #Arch #RPM
📖 Our entry: (homeless)
🥁️ Update: 0.11.1
⚗️ Code improvement 🚀️
📌️ Changes: https://github.com/wolfpld/tracy/releases
🦣️ From: 🛜️ https://github.com/wolfpld/tracy/releases.atom
🦝️ https://www.youtube.com/embed/fB5B46lbapc
🦝️ https://www.youtube.com/embed/W9U5y5jjQDM
💎 https://www.youtube.com/embed/JF5F6iqrQdQ
🕯️https://www.youtube.com/embed/K33CPCQcF14
🕶️ A view of its UI (on a dark theme) with its menus at the top in the form of buttons and a few indicators, and on the rest of the screen a timeline over a few ms, the operating chronology of the processor threads, below the details of the operation of thread 336, below and to the sides tables and curves describing the processes in progress.
📚️ A libre, multi-platform real-time profiler for game development, with nanosecond resolution, remote telemetry, hybrid pre-sampling and framing. By integrating calls to the library in the source code of an application, developers can measure the performance of their code and detect sources of slowdown, with a view to optimizing speed and fluidity. It supports CPU and GPU profiling, memory allocation, locks, context switching, automatic assignment of screenshots to captured images, and much more.
📜️ "A libre real-time profiler for game development" 📜️
Profiler for games
A real time, nanosecond resolution, remote telemetry, hybrid frame and sampling profiler for games and other applications.
Tracy supports profiling CPU (Direct support is provided for C, C++, and Lua integration. At the same time, third-party bindings to many other languages exist on the internet, such as Rust, Zig, C#, OCaml, Odin, etc.), GPU (All major graphic APIs: OpenGL, Vulkan, Direct3D 11/12, OpenCL.), memory allocations, locks, context switches, automatically attribute screenshots to captured frames, and much more.
Quick-start guide
For Tracy to profile your application, you will need to integrate the profiler into your application and run an independent executable that will act both as a server with which your application will communicate and as a profiling viewer. The most basic integration looks like this:
• Add the Tracy repository to your project directory.
• Tracy source files in the project/tracy/public directory.
• Add TracyClient.cpp as a source file.
• Add tracy/Tracy.hpp as an include file.
• Include Tracy.hpp in every file you are interested in profiling.
• Define TRACY_ENABLE for the WHOLE project.
• Add the macro FrameMark at the end of each frame loop.
• Add the macro ZoneScoped as the first line of your function definitions to include them in the profile.
• Compile and run both your application and the profiler server.
• Hit Connect on the profiler server.
• Tada! You’re profiling your program!
There’s much more Tracy can do, which can be explored by carefully reading this manual. In case any problems should surface, refer to section 2.1 to ensure you’ve correctly included Tracy in your project.
Additionally, you should refer to section 3 to make sure you are using FrameMark, ZoneScoped, and any other Tracy constructs correctly.
A quick look at Tracy Profiler
Tracy is a real-time, nanosecond resolution hybrid frame and sampling profiler that can you can use for remote or embedded telemetry of games and other applications. It can profile CPU, GPU, memory allocations, locks, context switches, automatically attribute screenshots to captured frames, and much more.
While Tracy can perform statistical analysis of sampled call stack data, just like other statistical profilers (such as VTune, perf, or Very Sleepy), it mainly focuses on manual markup of the source code. Such markup allows frame-by-frame inspection of the program execution. For example, you will be able to see exactly which functions are called, how much time they require, and how they interact with each other in a multi-threaded environment. In contrast, the statistical analysis may show you the hot spots in your code, but it cannot accurately pinpoint the underlying cause for semi-random frame stutter that may occur every couple of seconds.
Even though Tracy targets frame profiling, with the emphasis on analysis of frame time in real-time applications (i.e. games), it does work with utilities that do not employ the concept of a frame. There’s nothing that would prohibit the profiling of, for example, a compression tool or an event-driven UI application.
You may think of Tracy as the RAD Telemetry plus Intel VTune, on overdrive.
1.1 Real-time
The concept of Tracy being a real-time profiler may be explained in a couple of different ways:
1. The profiled application is not slowed down by profiling. The act of recording a profiling event has virtually zero cost – it only takes a few nanoseconds. Even on low-power mobile devices, execution speed has no noticeable impact.
2. The profiler itself works in real-time, without the need to process collected data in a complex way. Actually, it is pretty inefficient in how it works because it recalculates the data it presents each frame anew. And yet, it can run at 60 frames per second.
3. The profiler has full functionality when the profiled application runs and the data is still collected. You may interact with your application and immediately switch to the profiler when a performance drop occurs.
1.2 Nanosecond resolution
It is hard to imagine how long a nanosecond is. One good analogy is to compare it with a measure of length.
Let’s say that one second is one meter (the average doorknob is at the height of one meter).
One millisecond (1/1000 of a second) would be then the length of a millimeter. The average size of a red ant or the width of a pencil is 5 or 6 mm. A modern game running at 60 frames per second has only 16 ms to update the game world and render the entire scene.
One microsecond (1/1000 of a millisecond) in our comparison equals one micron. The diameter of a typical bacterium ranges from 1 to 10 microns. The diameter of a red blood cell or width of a strand of spider web silk is about 7 μm.
And finally, one nanosecond (1/1000 of a microsecond) would be one nanometer. The modern microprocessor transistor gate, the width of the DNA helix, or the thickness of a cell membrane are in the range of 5 nm. In one ns the light can travel only 30 cm.
Tracy can achieve single-digit nanosecond measurement resolution due to usage of hardware timing mechanisms on the x86 and ARM architectures4. Other profilers may rely on the timers provided by the operating system, which do have significantly reduced resolution (about 300 ns – 1 μs). This is enough to hide the subtle impact of cache access optimization, etc.
1.2.1 Timer accuracy
You may wonder why it is vital to have a genuinely high resolution timer. After all, you only want to profile functions with long execution times and not some short-lived procedures that have no impact on the application’s run time.
It is wrong to think so. Optimizing a function to execute in 430 ns, instead of 535 ns (note that there is only a 100 ns difference) results in 14 ms savings if the function is executed 18000 times. It may not seem like a big number, but this is how much time there is to render a complete frame in a 60 FPS game. Imagine that this is your particle processing loop.
(...)
Un profileur temps réel libre pour le développement de jeux, par la Tracy Profiler Team.
En C++/C.
Tracy Profiler est un profileur temps réel libre et multi-plateforme pour le développement de jeux, avec une résolution de l'ordre de la nanoseconde, une télémétrie à distance, un pré-échantillonnage et une trame hybrides. En intégrant les appels à la bibliothèque dans le code source d'une application, les développeurs peuvent mesurer la performance de leur code et détecter les sources de ralentissement, en vue d'optimiser la rapidité et la fluidité. Il prend en charge le profilage du CPU, GPU, les allocations de mémoire, les verrous, les changements de contexte, l'attribution automatique de captures d'écran aux images capturées, et bien d'autres choses encore.
Profileur pour les jeux
Un profileur en temps réel, avec une résolution de l'ordre de la nanoseconde, une télémétrie à distance, un pré-échantillonnage et une trame hybrides pour les jeux et d'autres applications.
Tracy prend en charge le profilage du CPU (un support direct est fourni pour l'intégration du C, du C++ et du Lua. Parallèlement, des bindings tiers pour de nombreux autres langages existent sur Internet, tels que Rust, Zig, C#, OCaml, Odin, etc.), GPU (toutes les API graphiques majeures : OpenGL, Vulkan, Direct3D 11/12, OpenCL.), les allocations de mémoire, les verrous, les changements de contexte, l'attribution automatique de captures d'écran aux images capturées, et bien d'autres choses encore.
Guide de démarrage rapide
Pour que Tracy puisse profiler votre application, vous devrez intégrer le profileur dans votre application et exécuter un exécutable indépendant qui agira à la fois comme un serveur avec lequel votre application communiquera et comme une visionneuse de profilage. L'intégration la plus basique se présente comme suit :
• Ajoutez le dépôt Tracy à votre répertoire de projet.
• Placez les fichiers source de Tracy dans le répertoire project/tracy/public.
• Ajoutez TracyClient.cpp comme fichier source.
• Ajouter tracy/Tracy.hpp comme fichier include.
• Inclure Tracy.hpp dans tous les fichiers que vous souhaitez profiler.
• Définir TRACY_ENABLE pour l'ensemble du projet.
• Ajoutez la macro FrameMark à la fin de chaque boucle d'image.
• Ajoutez la macro ZoneScoped comme première ligne de vos définitions de fonctions pour les inclure dans le profil.
• Compilez et exécutez votre application et le serveur de profilage.
• Cliquez sur Connect sur le serveur de profilage.
• Tada ! Vous êtes en train de profiler votre programme !
Tracy peut faire bien d'autres choses, qui peuvent être explorées en lisant attentivement ce manuel. En cas de problème, reportez-vous à la section 2.1 pour vous assurer que vous avez correctement inclus Tracy dans votre projet.
De plus, vous devriez vous référer à la section 3 pour vous assurer que vous utilisez correctement FrameMark, ZoneScoped, et toute autre construction de Tracy.
Un aperçu de Tracy Profiler
Tracy est un profileur de trame et d'échantillonnage hybride en temps réel, avec une résolution de l'ordre de la nanoseconde, que vous pouvez utiliser pour la télémétrie à distance ou embarquée de jeux et d'autres applications. Il peut profiler le CPU, le GPU, les allocations de mémoire, les verrous, les changements de contexte, attribuer automatiquement des captures d'écran aux images capturées, et bien plus encore.
Bien que Tracy puisse effectuer une analyse statistique des données échantillonnées de la pile d'appels, tout comme d'autres profileurs statistiques (tels que VTune, perf ou Very Sleepy), il se concentre principalement sur le balisage manuel du code source. Ce balisage permet une inspection image par image de l'exécution du programme. Par exemple, vous pourrez voir exactement quelles fonctions sont appelées, combien de temps elles prennent et comment elles interagissent les unes avec les autres dans un environnement multithread. En revanche, l'analyse statistique peut vous montrer les points chauds de votre code, mais elle ne peut pas identifier avec précision la cause sous-jacente des saccades d'images semi-aléatoires qui peuvent se produire toutes les deux secondes
Même si Tracy cible le profilage des trames, en mettant l'accent sur l'analyse du temps de trame dans les applications en temps réel (c'est-à-dire les jeux), il fonctionne avec des utilitaires qui n'emploient pas le concept de trame. Rien n'interdit le profilage, par exemple, d'un outil de compression ou d'une application d'interface utilisateur pilotée par les événements.
Vous pouvez considérer Tracy comme le RAD Telemetry plus Intel VTune, surmultiplié.
1.1 Temps réel
Le concept de Tracy en tant que profileur en temps réel peut être expliqué de différentes manières :
1. L'application profilée n'est pas ralentie par le profilage. L'enregistrement d'un événement de profilage a un coût pratiquement nul - il ne prend que quelques nanosecondes. Même sur les appareils mobiles de faible puissance, la vitesse d'exécution n'a pas d'impact notable.
2. Le profileur lui-même fonctionne en temps réel, sans qu'il soit nécessaire de traiter les données collectées de manière complexe. En fait, son fonctionnement est assez inefficace, car il recalcule les données qu'il présente à chaque image. Et pourtant, il peut fonctionner à 60 images par seconde.
3. Le profileur est pleinement fonctionnel lorsque l'application profilée s'exécute et que les données sont toujours collectées. Vous pouvez interagir avec votre application et passer immédiatement au profileur lorsqu'une baisse de performance se produit.
1.2 Résolution à la nanoseconde
Il est difficile d'imaginer la durée d'une nanoseconde. Une bonne analogie consiste à la comparer à une mesure de longueur.
Disons qu'une seconde correspond à un mètre (la poignée de porte moyenne se trouve à une hauteur d'un mètre).
Une milliseconde (1/1000 de seconde) correspondrait alors à la longueur d'un millimètre. La taille moyenne d'une fourmi rouge ou la largeur d'un crayon est de 5 ou 6 mm. Un jeu moderne fonctionnant à 60 images par seconde ne dispose que de 16 ms pour mettre à jour l'univers du jeu et rendre toute la scène.
Dans notre comparaison, une microseconde (1/1000 de milliseconde) équivaut à un micron. Le diamètre d'une bactérie typique varie de 1 à 10 microns. Le diamètre d'un globule rouge ou la largeur d'un fil de toile d'araignée est d'environ 7 μm.
Enfin, une nanoseconde (1/1000 de microseconde) correspond à un nanomètre. La porte du transistor d'un microprocesseur moderne, la largeur de l'hélice d'ADN ou l'épaisseur d'une membrane cellulaire sont de l'ordre de 5 nm. En une ns, la lumière ne peut parcourir que 30 cm.
Tracy peut atteindre une résolution de mesure de l'ordre de la nanoseconde grâce à l'utilisation de mécanismes de synchronisation matériels sur les architectures x86 et ARM4. D'autres profileurs peuvent s'appuyer sur les temporisateurs fournis par le système d'exploitation, qui ont une résolution considérablement réduite (environ 300 ns - 1 μs). Cela suffit à masquer l'impact subtil de l'optimisation de l'accès au cache, etc.
1.2.1 Précision de la minuterie
Vous pouvez vous demander pourquoi il est vital d'avoir un timer véritablement à haute résolution. Après tout, vous ne voulez profiler que les fonctions dont le temps d'exécution est long, et non certaines procédures de courte durée qui n'ont aucun impact sur le temps d'exécution de l'application.
C'est une erreur. Optimiser une fonction pour qu'elle s'exécute en 430 ns au lieu de 535 ns (notez que la différence n'est que de 100 ns) permet de gagner 14 ms si la fonction est exécutée 18 000 fois. Ce chiffre peut sembler peu élevé, mais c'est le temps qu'il faut pour rendre une image complète dans un jeu à 60 FPS. Imaginez qu'il s'agisse de votre boucle de traitement des particules.
(...)