RFC: Tracy as a "standalone" sampling profiler?

[slomp]

I think it should be possible, with relatively few changes, to make Tracy a "standalone" sampling-based profiler.

Right now, when we setup sampling, we look for activity related to the PID of the process where the Tracy client code resides. We could have a tool which would "launch" (or even attach to) a process and set the PID of the sampling engine to that of the external/managed process.

[slomp]

(we'd also need to modify some APIs related to symbol resolution to look externally to another process, but that's doable)

[wolfpld]

#489

[slomp]

Thanks!

Yeah, fork() would not work on Windows anyway. I'll see if I can make a proof-of-concept that piggy-backs on (and extends) the existing TracyClient.cpp code.

The idea would be to:

• launch the external process, get its PID
• start ETW and filter StackWalk events for that PID
• use SymGetModuleInfo64 to retrieve the module base address of the callstack frames of the external process
• then use SymLoadModuleEx to load the symbols for that module
• finally, use SymFromAddr to get the actual symbol (and offset)

[Lectem]

I have been thinking about something related recently: we probably want to be able to merge / convert an .etl file to a tracy capture. Another (simpler ?) approach is to inject Tracy as a .dll into the process directly.

[slomp]

inject Tracy as a .dll into the process directly.

Yeah, this could work. DLL injection is becoming more difficult on recent Windows versions, but since it needs to run with elevated privileges anyway, it should work reliably.