Re: timevar: further work

[Akim Demaille]

> Le 10 oct. 2018 à 23:50, Bruno Haible <address@hidden> a écrit :
> 
> Just make sure that the user understands that the wall clock timings
> have microsecond resolution wheras the user+system time values have
> a lower resolutions. Since they are in the same line of output, it's
> not obvious to understand.

Ok.  But since really, this tool is not for high quality profile,
but just to get cost estimates, I did not aim at that level of
precision.

> What would be the best way to clarify this? By using an appropriate
> number of decimal digits?
> 
> Execution times (seconds)
> read                  :   0.091 (19%) usr   0.080 (80%) sys   0.090242 (18%) 
> wall
> read: scan            :   0.043 ( 9%) usr   0.080 (80%) sys   0.123492 (26%) 
> wall
> read: parse           :   0.056 (10%) usr   0.000 ( 0%) sys   0.052384 (10%) 
> wall
> work                  :   0.333 (70%) usr   0.000 ( 0%) sys   0.353432 (71%) 
> wall
> work: phase 1         :   0.301 (64%) usr   0.000 ( 0%) sys   0.307234 (64%) 
> wall
> work: phase 2         :   0.139 (28%) usr   0.000 ( 0%) sys   0.144232 (29%) 
> wall
> output                :   0.043 ( 9%) usr   0.020 (20%) sys   0.040233 ( 8%) 
> wall
> total time            :   0.474             0.100             0.492343
> 
> Or by using column headers?
> 
> Execution times (seconds)
>                          CPU user      CPU system    wall clock
>                          (4 ms res.)   (4 ms res.)   (1 µs res.)
> read                  :   0.091 (19%)   0.080 (80%)   0.090242 (18%)
> read: scan            :   0.043 ( 9%)   0.080 (80%)   0.123492 (26%)
> read: parse           :   0.056 (10%)   0.000 ( 0%)   0.052384 (10%)
> work                  :   0.333 (70%)   0.000 ( 0%)   0.353432 (71%)
> work: phase 1         :   0.301 (64%)   0.000 ( 0%)   0.307234 (64%)
> work: phase 2         :   0.139 (28%)   0.000 ( 0%)   0.144232 (29%)
> output                :   0.043 ( 9%)   0.020 (20%)   0.040233 ( 8%)
> total time            :   0.474         0.100         0.492343

I clearly prefer the second one, not because it specifies the
precision, but because it factors details.

Also, I don’t think it makes sense to have more than 2 digits
of precision: we are very likely to be within noise already
with 2.