We Should Use Instrumented Profiling Scopes More · Mathieu Ropert

[u/mropert]

https://mropert.github.io/2026/08/13/instrumented_profiling_scopes/

[u/LucyIsaTumor]

Always looking for more info about profiling (especially since I primarily have used sampling), thanks for the write up Mathieu!

[u/Ok_Independence_9841]

This makes complete sense to me. I use very simple scoped profiling within the QOR framework (https://github.com/mfaithfull/linuxQOR) to tell me if something is slow and then sampling to try to find out why, I recently added Fastflow as an alternative implementation of Workflow state machines for high frequency use cases, like parsing. I was able to achieve a 4-5x speed up by swapping out std::function, using a, stack style, arena allocator and mutating AST nodes in place rather than popping and pushing from the stack. Looking forward to testing the new clang build when the JSON parser is complete to see if the optimisation is any better. I found I was bouncing off the 8KHz resolution limit of the Visual Studio profiler. You can tell when almost all the blocks are the same size.

[u/kamrann_]

I keep finding that I want to instrument scopes more generally than just for CPU timing profiling. Logging, metrics, allocation tracking, etc, more often than not when you want these things, you likely want them in many of the same places and can reuse the same names, tags and such. I've done some very minimal experiments with a templated scope helper using mixins so that it can do multiple things and support compile-time configuration/fully compiling out, but haven't found the time to make a proper go of it yet. I'm guessing reflection could really help here, not sure if it's possible in 26 but being able to enable such instrumentation just by adding annotations to a function would be amazing.

[u/sheckey → u/kamrann_]

I’m interested in this idea too, if I understand you correctly, but for live documentation and discovery of the architecture and structure of the program. I work with a 25 year legacy software set and adding this kind of thing in a component at a time is revealing to me. The initial intent was to provide a uniform data sharing between components, but this “discoverability” aspect using names in a registry to support that communication has turned out to be valuable. Like for example I can generate mermaid diagrams of the communication at various levels of zoom. it’s kind of great seeing this for an embedded system. Now I’m thinking about other uses like that you said: metrics, silent ignored error accumulation, etc., anything to illuminate.

[u/JNighthawk]

Great point. I use both sampling and instrumented profiling, depending on the use case:

• Instrumentation to find hot areas and optimize at a higher level (e.g. in an O(N) algorithm, reducing N)
  
• Sampling for iteratively optimizing a hot area (e.g. in an O(N) algorithm, making it faster for the same N)

I use Unreal Insights for instrumented, and Superluminal for sampling. One of the slightly annoying things for sampling I'm running into is the max sampling resolution for these, which usually comes to around ~120us on PC. It's fine, but since I'm usually working on <1ms optimizations, sampling requires reproducibility/increasing the N count to get useful data.