CPU and wall clock in "Transition to unmanaged code"

alexlea

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?

alexlea

I contacted support and it appears unmanaged code always shows wall clock time.

Andrew H

I hate to contradict support, but this isn't actually true: the one kind of unmanaged profiling the profiler does is against functions that cause blocking, so blocking time in unmanaged function calls should be accounted for.

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.

alexlea

Thanks for the update, very useful to know.

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