Change the usec_per_call operation from float to long long division

[bluayer]

Affected command by this change

INFO commandstats

Changed results example

cmdstat_set:calls=2,usec=36,usec_per_call=18,rejected_calls=1,failed_calls=0 cmdstat_get:calls=3,usec=13,usec_per_call=4,rejected_calls=1,failed_calls=0 cmdstat_info:calls=6,usec=444,usec_per_call=74,rejected_calls=0,failed_calls=0 cmdstat_command|docs:calls=2,usec=3951,usec_per_call=1975,rejected_calls=0,failed_calls=0

Context

The usec_per_call is a simple AVG metric that divides the execution time by the number of calls. However, it was performing the calculation by converting long long to float. For two reasons, usec_per_call does not require the high accuracy of a float level:

1. There are not many reasons to know the average value in units smaller than microseconds.
2. It currently displays the value of only two digits after the decimal point for accuracy

Therefore, I propose changing the implementation to a simple long long division operation without the floating-point conversion and computation.

This change will benefit users who are using various commands in valkey and using high-resolution metrics in commandstats.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 71.02%. Comparing base (d56a1f7) to head (017fbe6).

Additional details and impacted files

@@             Coverage Diff              @@
##           unstable    #1888      +/-   ##
============================================
- Coverage     71.06%   71.02%   -0.04%     
============================================
  Files           123      123              
  Lines         65671    65671              
============================================
- Hits          46669    46646      -23     
- Misses        19002    19025      +23     

Files with missing lines	Coverage Δ
src/server.c	87.54% <100.00%> (ø)

... and 9 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[zuiderkwast]

Please mention in the PR title or top comment which command is affected by this change.

A possible workaround: It's possible call INFO with a specific section (e.g. INFO server), to avoid computing this info section.

[zuiderkwast]

This will change the format slightly from 1.00 to 1.

I think it's right to remove the sub-microsecond part. We only measure the execution time in microseconds anyway, so this is already not exact on sub-microsecond level.

We should probably label it as a potentially breaking change though, just in some case some tool is parsing this and expect the period to be there.

[xbasel]

I think sub-microsecond latency is useful - why not modify getMonotonicUs to return nanoseconds instead (getMonotonicNs)? both __rdtsc/__cntvct can provide sub-microsecond precision...

[xbasel]

I have some concerns about this change.

It breaks existing behavior, commands that take <1µs will now just show 0, which looks off and we lose useful precision, especially when profiling fast commands.

I still don’t quite understand why this change is needed, could you provide an example where the current float-based calculation causes issues?

UPDATE: Saw that the precision in µs, this means the reported usec_per_call is not accurate. So we either fix the accuracy or we remove these decimal digits (which is what this change is doing)...