Hi Alberto,

Thanks for posting. Can you confirm whether the issue you're experiencing is with how these values are being rendered, or is it the data itself? (i.e. you don't expect it to be zero).

The documentation link you've quoted applies only to the intensity of the yellow interiors on the coverage markers. It has no effect on the Metrics/HotSpots Window. The size of bars in these windows are calculated as a proportion of the longest time shown in the list (i.e. it's completely relative and not controlled by config).

Not always. If your code is fast, and you aren't stress testing it, a 0ms execution time can actually be quite normal.

The best way to check whether the measurement is working is to try adding Thread.Sleep somewhere in the execution path. This should show up very noticeably in the hot spots view.

The performance metrics measure wall time for individual lines of code, and do not have special handling for async/await. This means that if you have a test suspended using async/await, the delay will not usually be captured by NCrunch as the thread involved is either held or retasked outside of the instrumented code blocks. This would be my best guess as to why you aren't seeing this tracked in the performance metrics. There may be ways you can work around this by managing the async delays yourself so that the thread control is not transferred outside your own code.

I feel the best way to control this would be in your test code itself. The test code is responsible for calling into the system under test, and as such it has the ability to control the lifespan of the controlling thread. If you are working with test methods marked with 'async', the handling (and waiting) of the async blocks is pushed upward into the runner. This contrasts with having a test that controls async calls using the static Task methods, which controls the waiting on execution itself.

There may be some real hard limits to how effectively we can measure performance in a system making extensive use of async/await. Particularly when the lower level tasks responsible for a given bottleneck are being performed in library code which isn't instrumented by NCrunch. This is just the nature of async. NCrunch measures performance by examining line wall times on a held thread, which doesn't detect threads that are unwound through async's continuations. Maybe at some stage we might find a better way to handle this in NCrunch itself, but we'd need to break some big abstractions to do it... So I don't see this happening anytime soon.