Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide a way to monitor "cycles" #5

Open
benjymous opened this issue Aug 23, 2013 · 8 comments
Open

Provide a way to monitor "cycles" #5

benjymous opened this issue Aug 23, 2013 · 8 comments

Comments

@benjymous
Copy link
Contributor

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)

@CyberShadow
Copy link
Member

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?

@d-led
Copy link

d-led commented Sep 12, 2013

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?

@benjymous
Copy link
Contributor Author

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)

@mojomojomojo
Copy link
Contributor

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

@CyberShadow
Copy link
Member

@mojomojomojo
Copy link
Contributor

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?

@CyberShadow
Copy link
Member

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
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants