I am currently using tracy to profile a program I am writing. Tracy as a tool seems quite awesome, but it has one issue.

You need to markup your code when profiling. This has the negative consequence of obfuscating readability by introducing code that is unrelated to the functionality of the functions being profiled.

One option is to delete the markup as soon as you are done profiling, but it can become tedious to introduce and delete the markups each time profiling is needed.

As such I am trying to think of the least invasive way to introduce Tracy's markup and the most flexible way.

For example this is a marked zone:

    NECore::ModuleData module_data = {};
    module_data.renderer_so_path = NE_RENDERER_PATH;
    module_data.peripheral_so_path = NE_PERIPHERAL_PATH;


    window = InitWindow();
    vk_meta_data = InitializeRendering(window->GetGLFWWindow());

    LogLoadedState(module_data, vk_meta_data);

I could put it beside the bracket to make it clear this is not logically a part of the function:

{ ZoneScoped

I could add a comment after each mark (but this is tedious).

I could make a script that removes them and readds them on demand (but this seems like a bad idea).

1 Answer 1


Some things don't have a satisfying solution. Cross-cutting concerns like logging, tracing, and profiling must be part of the code, even though they distract from the surrounding business logic. Sometimes the necessary parts can be bundled up into macros specific to your project, but Tracy already supports such macros and it will be difficult to reduce this syntactic noise even further.

To disable/enable tracing, do not edit all of the functions. Instead, use the features the language already gives you, in particular the preprocessor. For example, #define the tracing macros as empty if you want a build without tracing (which, incidentally, already is the default if you compile without TRACY_ENABLE). Or use Tracy's built-in filtering support (boolean active parameter of the ZoneNamed() macro).

You suggest adding a script to add/remove the necessary markers for tracing, but I'd strongly recommend against this. Such scripts are difficult to write reasonably correctly because C++ is a very complex language. The script could easily break something. If the scripts rely on special formatting conventions, those conventions might not survive a pass from an auto-formatter like clang-format. The versions with and without tracing would be a different codebase, making it e.g. difficult to compare line numbers. Instead, strongly consider keeping your code base as unified as possible and introducing different variants of your code only through the build process, in particular through careful use of ifdefs.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.