Reported durations are 100x too large on Linux

[benbryant0]

The durations reported by MiniProfiler when run on Linux are 100x larger than they should be.

This is caused by the change here which was released as 4.2.43.

Stopwatch ticks are not the same as DateTime or TimeSpan ticks (because that's not going to confuse anyone 🙄) so using TimeSpan.TicksPerMillisecond to convert is not reliable. Previous versions of MiniProfiler correctly used Stopwatch.Frequency to account for this. See this doc page for an explanation: https://docs.microsoft.com/en-us/dotnet/api/system.diagnostics.stopwatch.elapsedticks?view=net-6.0#remarks

Simple example comparing Ubuntu & Windows output:

using StackExchange.Profiling;
using System.Diagnostics;

var stopwatch = Stopwatch.StartNew();
Thread.Sleep(1000);
stopwatch.Stop();

Console.WriteLine(@$"Running under: {System.Runtime.InteropServices.RuntimeInformation.RuntimeIdentifier}
Stopwatch:
    ElapsedTicks: {stopwatch.ElapsedTicks}
    ElapsedMilliseconds: {stopwatch.ElapsedMilliseconds}
TimeSpan.TicksPerMillisecond: {TimeSpan.TicksPerMillisecond}");

var profiler = new MiniProfiler("", new());

using (var _ = profiler.Step("")) {
    Thread.Sleep(1000);
}

profiler.Stop();

Console.WriteLine($"Profiler duration ms: {profiler.DurationMilliseconds}");

[NickCraver]

Dammit! I was paranoid about this and ended up the wrong way. Can you give me a sanity check on this?

internal decimal GetRoundedMilliseconds(long ticks)
{
	long times100 = ticks * 100000 / Stopwatch.Frequency;
	return times100 / 100m;
}

Example program:

void Main()
{
	var ticksStart = Stopwatch.GetTimestamp();
	Thread.Sleep(1000);
	var ticksEnd = Stopwatch.GetTimestamp();
	Console.WriteLine(GetRoundedMilliseconds(ticksEnd - ticksStart));
}
internal decimal GetRoundedMilliseconds(long ticks)
{
	long times100 = ticks * 100000 / Stopwatch.Frequency;
	return times100 / 100m;
}

[benbryant0]

Yup, seems reasonable to me!

[NickCraver]

Fixed in #602 - thanks for the help!!