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: 50
Location: Italy

Was thanked: 1 time(s) in 1 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: 6,420

Thanks: 838 times
Was thanked: 1136 time(s) in 1062 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: 50
Location: Italy

Was thanked: 1 time(s) in 1 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: 6,420

Thanks: 838 times
Was thanked: 1136 time(s) in 1062 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: 1
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: 6,420

Thanks: 838 times
Was thanked: 1136 time(s) in 1062 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.
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.351 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download