Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error

Hotspot bars are all zero length
devdept
#1 Posted : Thursday, September 23, 2021 6:12:40 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 10/13/2012(UTC)
Posts: 53
Location: Italy

Was thanked: 2 time(s) in 2 post(s)
Hello,

What do I need to do to fix these zero-length hotspot bars?

https://www.screencast.com/t/dK39vGG67Qx

I've checked the documentation but it's not very easy to understand: https://www.ncrunch.net/...nce-display-sensitivity

Thanks,

Alberto
Remco
#2 Posted : Friday, September 24, 2021 12:51:09 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,007

Thanks: 935 times
Was thanked: 1261 time(s) in 1174 post(s)
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).
devdept
#3 Posted : Friday, September 24, 2021 8:38:02 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 10/13/2012(UTC)
Posts: 53
Location: Italy

Was thanked: 2 time(s) in 2 post(s)
Hi Remco,

Quote:
Can you confirm whether the issue you're experiencing is with how these values are being rendered, or is it the data itself?


Honestly, I don't know. It seems weird that all methods share the same zero computing time, isn't it?

I've instrumented only one project of a complex VStudio solution and all the *.cs files I've checked are the same.

Thanks,

Alberto
Remco
#4 Posted : Saturday, September 25, 2021 12:32:35 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,007

Thanks: 935 times
Was thanked: 1261 time(s) in 1174 post(s)
devdept;15659 wrote:

Honestly, I don't know. It seems weird that all methods share the same zero computing time, isn't it?


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.
jmwnoble
#5 Posted : Tuesday, October 5, 2021 10:04:48 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 10/10/2015(UTC)
Posts: 2
Location: Australia

I have a related issue. Running NCrunch against a .Net Core 5 solution, the performance metrics seem way off. An integration test that I watch taking 3 mins to run, has a hotspot on the parent method of 800ms when it should reflect the 3 mins it is actually taking.
If I put Thread.Sleep in, that gets measured correctly, but nothing else does. Do I need to check my setup? Could it be that the performance metrics are not aggregating correctly? An issue with async/await?
Thanks
Remco
#6 Posted : Tuesday, October 5, 2021 11:57:08 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,007

Thanks: 935 times
Was thanked: 1261 time(s) in 1174 post(s)
jmwnoble;15685 wrote:
I have a related issue. Running NCrunch against a .Net Core 5 solution, the performance metrics seem way off. An integration test that I watch taking 3 mins to run, has a hotspot on the parent method of 800ms when it should reflect the 3 mins it is actually taking.
If I put Thread.Sleep in, that gets measured correctly, but nothing else does. Do I need to check my setup? Could it be that the performance metrics are not aggregating correctly? An issue with async/await?
Thanks


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.
jmwnoble
#7 Posted : Thursday, April 13, 2023 12:38:05 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 10/10/2015(UTC)
Posts: 2
Location: Australia

Hi, I've come back to this issue because we never came up with an approach - did you have something specific in mind when you said "managing the async delays yourself so that the thread control is not transferred outside your own code" that would not require changes to the system under test, or at least changes that would not be counterproductive to going async in the first place? Thanks
Remco
#8 Posted : Friday, April 14, 2023 12:08:34 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,007

Thanks: 935 times
Was thanked: 1261 time(s) in 1174 post(s)
jmwnoble;16600 wrote:
Hi, I've come back to this issue because we never came up with an approach - did you have something specific in mind when you said "managing the async delays yourself so that the thread control is not transferred outside your own code" that would not require changes to the system under test, or at least changes that would not be counterproductive to going async in the first place? Thanks


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.
Users browsing this topic
Guest
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

YAF | YAF © 2003-2011, Yet Another Forum.NET
This page was generated in 0.063 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download