CPU and wall clock in "Transition to unmanaged code"
alexlea
Posts: 4
We're profiling a network application using Socket.Receive which quickly transitions to unmanaged code (recv method).
What's not clear is whether the profiler can distinguish between CPU time and wall clock time spent inside the managed code - i.e. Can the profiler identify time spent blocking in unmanaged code.
Our app is showing 37% of time in there so we really need to know if the figure for this unmanaged code section includes blocking or not.
Can anyone confirm how this works please?
What's not clear is whether the profiler can distinguish between CPU time and wall clock time spent inside the managed code - i.e. Can the profiler identify time spent blocking in unmanaged code.
Our app is showing 37% of time in there so we really need to know if the figure for this unmanaged code section includes blocking or not.
Can anyone confirm how this works please?
Comments
There can be limitations with this, however. In particular, we wanted to design the profiler so that it only instruments documented calls and doesn't require a kernel driver. This is problematic as it's possible there are some calls that we miss. Socket calls should be handled, although some of the bug reports I've seen indicate there is some other product (probably anti-virus or security related) that also intercepts these calls and interferes with the profiler, producing crashes or odd results.
I can't comment on your particular case without seeing some working example code: it's possible that a blocking call is being missed for some reason, or that the profiler is actually producing accurate results. We fixed some issues with this in v6, so it might be worth trying the EAP.
Software Developer
Red Gate Software Ltd.
Our wall clock and cpu time figures are very similar so that would indicate minimal blocking (good) if the figures are correct.
Won't rely on them too heavily however without further investigation.
Thanks