Replies: 1 comment
-
|
Yes, it's possible. The function with the most inclusive samples is usually going to be the first function that the operating system calls which then invokes the code paths that spend most CPU time (compared to other OS-invoked functions). This is typically closer to 100%, but various circumstances can cause other results. If Very Sleepy cannot walk the stack to reconstruct the call stack, it could cause such a result. This can happen if some code in the hot path is compiled with stack frames disabled; it's possible that this is the case for the DLL you're dealing with. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
I'm trying to profile my application (32bit in C++) which uses database via ODBC Driver 17 for SQL Server and i'm getting confusing results - the maximum "inclusive%" function was showing like 55-65% of samples. Is it possible that Sleepy has some problem taking a sample when the code execution is in there?
I tried MSDiagnostics.exe too, but got similarily weird results, too.
I haven't found any symbols for that DLL (msodbcsql17.dll) but that should not cause the "missing samples", right?
Anybody has seen something like that? .. Any ideas what I might be doing wrong / what to do next?
Beta Was this translation helpful? Give feedback.
All reactions