verysleepy icon indicating copy to clipboard operation
verysleepy copied to clipboard

Provide a way to monitor "cycles"

Open benjymous opened this issue 11 years ago • 8 comments

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)

benjymous avatar Aug 23 '13 09:08 benjymous

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?

CyberShadow avatar Aug 23 '13 13:08 CyberShadow

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?

d-led avatar Sep 12 '13 14:09 d-led

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)

benjymous avatar Sep 12 '13 14:09 benjymous

How would Very Sleepy "listen" for debug output from the target process?

mojomojomojo avatar Mar 22 '22 19:03 mojomojomojo

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?

mojomojomojo avatar Mar 22 '22 19:03 mojomojomojo

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).

CyberShadow avatar Mar 22 '22 19:03 CyberShadow

Note that we already have a debugger thread which calls WaitForDebugEvent in debugger.cpp. This was added in #88.

CyberShadow avatar Mar 22 '22 19:03 CyberShadow