CODEWITHSUNDEEP
c++debuggingwinapiassemblyetw
Hagay Myr
Hagay Myr

Reputation: 409

Optimizing Stack-Walking performance

Currently i use the dbghelp library to walk through the stack of some process' thread (using GetThreadContext() and StackWalk64()) and collect only the return addresses each frame contains.

However, the overhead of doing so is too big for the systems demands - overall time is apx. 5 msec per stack walk (with 10-15 frames). This time includes the GetThreadContext() and the loop which calls StackWalk64() to get all the frames.

Anyhow, I must find a way to do it much much faster. Anyone has any idea how can i do that?

Edit:

Does anyone know of the ETW (Event Tracing for Windows) mechanism?

If so, how can I trace all the context switches that happened in a certain period of time? Is there an event provider that publishes an event on each context switch?

Upvotes: 4

Views: 1840

Answers (3)

mjsabby
mjsabby

Reputation: 1139

If you're on Windows Vista or higher, you should use ETW, period. You can activate all what you're talking about, including Context Switches and Sample Profile events, and it's pretty efficient. For X86, it's basically walking the EBP register chain, which is a linked list of addresses that it needs to iterate over. In 64-bit land, the stack walker has to unwind the stack, and so it's a little less efficient, but I can tell you if you're doing any reasonable amount of work in your application, the effects of stack walking will not show up. It's certainly not in the millisecond range.

Upvotes: 2

Uri Cohen
Uri Cohen

Reputation: 3608

The ETW part is actually an independent question. Windows Performance Analysis Tools can capture all context-switches, as well as Visual Studio Profiler in "Resource Contention Concurrency Profiling" mode. You can also dump all events into file manually using logman, see the instructions here.

Upvotes: 1

JosephH
JosephH

Reputation: 8815

The fastest way that I can think of is to create your own version of GetThreadContext and StackWalk64 by creating a kernel driver that grabs the kernelStack field of ETHREAD structure of the thread your trying to monitor. Here is a good article on this subject.

Upvotes: 4

Related Questions