Fixed wrong time calc in dotnetspy.

[AdrK]

No description provided.

[AdrK]

The examples/dotnet/web was not working and I found that this is due to wrong calculations here.
I wonder why we were doing /10 ? For v.Milliseconds() == 1, this was resolving to 0 and no samples were reported in stacktrace.

[kolesnikovae]

It's a leftover. Thank you for fixing this!

[kolesnikovae]

LGTM.

I've also updated dotnetdiag package - could you please bump its version to v1.2.1?

[petethepig]

@kolesnikovae So that must mean we should be seeing more data now when we profile dotnet apps, right?

[codecov]

Codecov Report

Merging #252 (7144e59) into main (2723d11) will increase coverage by 0.03%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #252      +/-   ##
==========================================
+ Coverage   54.18%   54.20%   +0.03%     
==========================================
  Files          87       87              
  Lines        3631     3631              
==========================================
+ Hits         1967     1968       +1     
+ Misses       1465     1464       -1     
  Partials      199      199              

Impacted Files	Coverage Δ
pkg/agent/upstream/remote/remote.go	62.32% <0.00%> (-2.89%)	⬇️
pkg/agent/session.go	66.40% <0.00%> (+2.46%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2723d11...7144e59. Read the comment docs.

[kolesnikovae]

My bad, this denominator is not a mistake - #255:

// dotnet profiler reports total time v per call stack k.
// Meanwhile, pyroscope agent expects number of samples is
// reported. Every sample is a time fraction of second
// according to sample rate: 1000ms/100 = 10ms by default.
// To represent reported time v as a number of samples,
// we divide it by sample duration.
//
// Taking into account that under the hood dotnet spy uses
// Microsoft-DotNETCore-SampleProfiler, which captures a
// snapshot of each thread's managed callstack every 10 ms,
// we cannot manage sample rate from outside.

Thus, we cannot capture samples of duration less than 1s/sample-rate (10ms by default).

@AdrK, the reason why web example didn't show anything is that we filter out "unmanaged" code (native): unless there are no incoming requests, collected profiles will be empty (though, sometimes on slow machines we can capture time spent in managed code that invokes native methods).