mirror of
https://github.com/wolfpld/tracy.git
synced 2024-11-10 10:41:50 +00:00
Frame profiler
gamedevgamedev-librarygamedevelopmentlibraryperformanceperformance-analysisprofilerprofilingprofiling-library
9f2ffb05ac
Consider running the following code with operator new and delete overloaded to track allocations with call stacks: std::thread( []({ thread_local std::string str; }); Each call stack requires a memory allocation to be performed by the profiler, to make the stack available at a later time. When the thread is created, the TLS block is initialized and the std::string buffer can be allocated. To track this allocation, rpmalloc has to be initialized. This initialization also happens within the TLS block. Now, when the thread exits, the heap managed by rpmalloc may be released first during the TLS block destruction (and if the destruction is performed in reverse creation order, then it *will* be destroyed first, as rpmalloc was initialized only after the std::string initialization, to track the allocation performed within). The next thing to happen is destruction of std::string and release of the memory block it contains. The release is tracked by the profiler, and as mentioned earlier, to save the call stack for later use, a memory allocation is needed. But the allocator is no longer available in this thread, because rpmalloc was released just before! As a solution to this issue, profiler will detect whether the allocator is still available and will ignore the call stack, if it's not. The other solution is to disable the rpmalloc thread cleanup, which may potentially cause leak-like behavior, in case a large number of threads is spawned and destroyed. Note that this is not a water-tight solution. Other functions will still want to allocate memory for call stacks, but it is rather unlikely that such calls would be performed during TLS block destruction. It is also possible that the event queue will run out of allocated space for events at this very moment, and in such a case the allocator will also fail. |
||
---|---|---|
.github | ||
.vscode | ||
capture | ||
client | ||
common | ||
csvexport | ||
doc | ||
examples | ||
extra | ||
getopt | ||
icon | ||
imgui | ||
import-chrome | ||
libbacktrace | ||
library | ||
manual | ||
nfd | ||
profiler | ||
server | ||
test | ||
update | ||
vcpkg | ||
zstd | ||
.gitignore | ||
AUTHORS | ||
CMakeLists.txt | ||
LICENSE | ||
meson.build | ||
NEWS | ||
README.md | ||
TODO | ||
Tracy.hpp | ||
TracyC.h | ||
TracyClient.cpp | ||
TracyD3D11.hpp | ||
TracyD3D12.hpp | ||
TracyLua.hpp | ||
TracyOpenCL.hpp | ||
TracyOpenGL.hpp | ||
TracyVulkan.hpp |
Tracy Profiler
A real time, nanosecond resolution, remote telemetry, hybrid frame and sampling profiler for games and other applications.
Tracy supports profiling CPU (C, C++11, Lua), GPU (OpenGL, Vulkan, OpenCL, Direct3D 11/12), memory, locks, context switches, per-frame screenshots and more.
- Documentation for usage and build process instructions
- Releases containing the documentation (
tracy.pdf
) and compiled Windows x64 binaries (Tracy-<version>.7z
) as assets - Changelog
Introduction to Tracy Profiler v0.2
New features in Tracy Profiler v0.3
New features in Tracy Profiler v0.4
New features in Tracy Profiler v0.5
New features in Tracy Profiler v0.6
New features in Tracy Profiler v0.7