4 ms·

Tracepoints are very expensive and will definitely make any performance traces incorrect

userbinator 10y ago
I don't know what you mean exactly by "expensive", but the time spent in profiling code should obviously not be counted, and it is quite simple to do so. The real point I'm trying to make is that tracepoints do not require any changes to the original code. They are entirely opt-in and if you do not choose to use them, your application won't have this extra useless code compiled into it. That said, the few times I've had to use Visual Studio's tracepoints, they were horribly slow. Apparently this is "by design": https://connect.microsoft.com/VisualStudio/feedback/details/934631/tracepoints-feature-is-very-slow https://connect.microsoft.com/VisualStudio/feedback/details/... Being an RE, I've implemented and used simple tracers that were more than 100x faster than VS' on hardware not quite as fast as that today (around a decade ago). Watching variables in memory and CPU registers changing in near-realtime is something I very much miss when I have to work in higher-level languages...
- MaulingMonkey 10y ago
  > I don't know what you mean exactly by "expensive", but the time spent in profiling code should obviously not be counted, and it is quite simple to do so. Only for the exceedingly trivial case where you exclude profiling CPU time from overall CPU time. Profiling to see when exactly you're CPU bound, and when you're disk bound? Eh. Profiling to see if false sharing is eating your lunch? Eh. Trying to see when you'll fail to make vsync and the framerate will hitch? Eh. I've had to #ifdef out tracing info that boiled down to "if (happensToBeFalse) {...}" in tight loops because it was throwing off my profiling results too much. Compiler and debugger injected tracing info isn't going to be any cheaper than that. > The real point I'm trying to make is that tracepoints do not require any changes to the original code. They are entirely opt-in and if you do not choose to use them, your application won't have this extra useless code compiled into it. Debugger injected tracing is useful, but hardly a panacea. You know this or you wouldn't have written your own tracers, most likely. When you have the source code, writing a separate tracer doesn't make sense - you just embed your stuff directly into your source code and #ifdef it out when necessary (same result: no "extra useless code".) Easier to add data to your events ("what file am I hanging on?") without performance killing deep copies, or reverse engineering structure offsets. No need to subvert platform security on e.g. Xbox One to figure out how to inject your own code at runtime. No need to deal with another process's address space. Sometimes tracing info is useful to leave in your release builds. Which is cheaper: A few rare if() checks and some dormant code? Or spending hours rebuilding, retesting, redeploying to the production machine that is experiencing some issue you need tracing info to diagnose? As long as you're not shoving it into your inner loops it's fine. An event on entry/exit of main is about as far away from an inner loop as you can manage. It's fine.

I don't know what you mean exactly by "expensive", but the time spent in profiling code should obviously not be counted, and it is quite simple to do so. The real point I'm trying to make is that tracepoints do not require any changes to the original code. They are entirely opt-in and if you do not choose to use them, your application won't have this extra useless code compiled into it. That said, the few times I've had to use Visual Studio's tracepoints, they were horribly slow. Apparently this is "by design": https://connect.microsoft.com/VisualStudio/feedback/details/934631/tracepoints-feature-is-very-slow https://connect.microsoft.com/VisualStudio/feedback/details/... Being an RE, I've implemented and used simple tracers that were more than 100x faster than VS' on hardware not quite as fast as that today (around a decade ago). Watching variables in memory and CPU registers changing in near-realtime is something I very much miss when I have to work in higher-level languages...

MaulingMonkey 10y ago
> I don't know what you mean exactly by "expensive", but the time spent in profiling code should obviously not be counted, and it is quite simple to do so. Only for the exceedingly trivial case where you exclude profiling CPU time from overall CPU time. Profiling to see when exactly you're CPU bound, and when you're disk bound? Eh. Profiling to see if false sharing is eating your lunch? Eh. Trying to see when you'll fail to make vsync and the framerate will hitch? Eh. I've had to #ifdef out tracing info that boiled down to "if (happensToBeFalse) {...}" in tight loops because it was throwing off my profiling results too much. Compiler and debugger injected tracing info isn't going to be any cheaper than that. > The real point I'm trying to make is that tracepoints do not require any changes to the original code. They are entirely opt-in and if you do not choose to use them, your application won't have this extra useless code compiled into it. Debugger injected tracing is useful, but hardly a panacea. You know this or you wouldn't have written your own tracers, most likely. When you have the source code, writing a separate tracer doesn't make sense - you just embed your stuff directly into your source code and #ifdef it out when necessary (same result: no "extra useless code".) Easier to add data to your events ("what file am I hanging on?") without performance killing deep copies, or reverse engineering structure offsets. No need to subvert platform security on e.g. Xbox One to figure out how to inject your own code at runtime. No need to deal with another process's address space. Sometimes tracing info is useful to leave in your release builds. Which is cheaper: A few rare if() checks and some dormant code? Or spending hours rebuilding, retesting, redeploying to the production machine that is experiencing some issue you need tracing info to diagnose? As long as you're not shoving it into your inner loops it's fine. An event on entry/exit of main is about as far away from an inner loop as you can manage. It's fine.