Needs to do actual CPU usage profiling

[MarkStevans]

Maybe I'm missing something, but as I understand it, VS takes almost-continuous snapshots of the stack in all/some of the threads in a Windows process. This is extremely helpful, but it doesn't directly indicate which functions are actually responsible for CPU usage, since some of the functions at the bottom of the stack block.

But there are a small, fixed number of functions that block in the Windows libraries. Why can't VS have a list of them, perhaps extensible by the user? The blockers would be interpreted as using zero CPU. Then, VS would be able to declare that any stack trace that doesn't end in a blocker is using CPU, and actually list the functions and their CPU usage....

[CyberShadow]

That's a great idea, but wouldn't the simpler solution be to check if the call stack ends with a syscall?

[MarkStevans]

Not sure I understand what you mean. Do you mean that a human being should just check if the stack ends in a Windows system call in order to manually compute CPU usage, or that VS could be enhanced so that it assumes that all Windows system calls are blockers or use zero CPU? Don't some system calls actually use CPU, at least System CPU?

If VS could have a default list of the presumed blockers, whether they're all system calls or just certain ones like "NtWaitForMultipleObjects", it might still need them to be editable for special situations....

[CyberShadow]

or that VS could be enhanced so that it assumes that all Windows system calls are blockers or use zero CPU?

Yes, as an option.

Don't some system calls actually use CPU, at least System CPU?

Yes, though I think non-blocking syscalls with exit very quickly, so even if you ignore samples ending with a syscall, you should still get a lot of samples ending with code that will invoke the syscall.

[PatrickVanCauteren]

I am using VerySleepy regularly and a while ago I also thought that measuring CPU time was more relevant than measuring real time. But I realized this is not necessarily true. After all, you profile your application to make it faster, and this includes not only the CPU time, but also the waiting time. So if your thread is blocked on a critical section, another mutex (and not spinning) or waiting on file I/O or database I/O, you want to include this in your profiling results, because your users don't care whether the application is slow because of CPU usage, or because of a mutex your application is waiting on. So I think measuring real time is still the most relevant measurement. When I want to leave out some waiting time caused by the user performing some UI action, I just use the "Set Root To..." functionality of Very Sleepy and dig into the call stacks.