verysleepy
verysleepy copied to clipboard
Provide a way to monitor "cycles"
e.g. some standard way we can expose a counter in the code being profiled, and an option to profile for N iterations, or until a particular variable gets a given value.
This would make it simpler to compare subsequent runs over the same code (e.g. optimising loops)
The profiler could listen to signals sent by the program when to start and stop profiling.
E.g. OutputDebugString("VERYSLEEPY_START\n")
and OutputDebugString("VERYSLEEPY_STOP\n")
Would that fit your needs?
I was about to propose something similar. What about some communication channel (pipe?) sleepy could be listening to, to which a running process could send a token, telling to start profiling, and then to stop?
The debug string option seems best to me, as other than the debug lines, it wouldn't need any other code changes.
Some use cases I can imagine:
- start and stop a single run of sleepy based on the start/stop debug commands
- start sleepy on the first debug command, and keep running until N have been processed (e.g. so you can do an average sample over 100 runs of a process)
- as above, but somehow keep each cycle's data separate, so you get multiple profiles which you can flick between and compare (e.g. you've found performance degrades over multiple runs of a process, and you want to compare subsequent runs to see what's happening)
How would Very Sleepy "listen" for debug output from the target process?
If you're only polling, and not truly waiting indefinitely, will you miss an event that happened in between waits? Or would we need a dedicated thread to wait for these events?
I think polling should work, otherwise there would be no way to reliably receive all debug events.
I suppose the implementation (OS) might block the debuggee process until the debugger reads the pending debug event(s).
Note that we already have a debugger thread which calls WaitForDebugEvent
in debugger.cpp
. This was added in #88.