gprof errors due to loss of precision/add more digits

[Vladimir Mezentsev]

On 9/10/21 4:26 AM, wsnyder@wsnyder.org wrote:
> As background I support Verilator, which generates applications where there are often 10K+ functions. These create a relatively flat profile that runs through gprof. The gprof report is then post-analyzed to combine some of the 10K+ results into 10-ish groupings.  What users are finding is that the sum of percentages of the groupings in some cases is only accounting for roughly 40% of the program time.

  Is the sum of the absolute time wrong too ?
If not, it means the calculation of percentages is wrong for group. It 
should not be a sum of percentages.


>
> This due to the gprof report. In that report, the sum of all of the various function's percentage column sums to only about 40%.  This is because there are many functions which print as in report as "0.00%", but really the number behind that might be up to e.g. "0.004%", and if we could sum all of those lost-to-truncation values we'd get 60% of the total program time.
>
> If I edit gprof's hist.c to print e.g. 9 digits of precision then all of the "missing" time is now accounted for, proving it is a rounding issue.
>
> 1. Is there any existing way to have gprof print sym->hist_time, and/or more precision in the time or percentage columns, to avoid this loss of data due to this precision issue?
>
> 2. Would a patch to add a gprof flag to print sym->hist.time e.g. 9 digits of precision be potentially accepted?
>
> 3. Any other suggestions?
>
> Thanks
>
> P.S. Saw a thread about gprofng being under development - suggest that also (optionally?) print many more digits!
>