[RFA, doc RFA] Include wallclock time in "maint time" output.

[Doug Evans]

On Mon, Sep 19, 2011 at 10:31 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Mon, 19 Sep 2011 21:11:37 -0700 (PDT)
>> From: dje@google.com (Doug Evans)
>>
>> It is often useful to see the wallclock time of commands.
>
> Actually, it would be much more useful to display time it took the
> inferior between two points where GDB gets control.  Are you trying to
> approximate that missing feature, or is there some other use case
> where wallclock time would be useful?

It's not always the case that the inferior is running when wanting to
see wallclock time.  E.g., remote protocol operations, excessive nfs
latency, etc.
[For reference sake, MI already supports this feature for monitoring
slow operations.]

>> This patch adds wallclock time to the output from "maint time 1".
>>
>> This patch depends on a patch for libiberty, pending approval.
>> http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01118.html
>> I'll revise this as appropriate, but can I get an RFA on the
>> addition of wallclock time to the output?
>>
>> [Other bits of gdb can make use of timeval-utils.h,
>> that's another patch.]
>
> IMO, it would be better to add to libiberty a couple of functions to
> measure interval times.  What you suggest is to call gettimeofday
> twice and then subtract the values.  But that assumes the resolution
> of gettimeofday is high enough to be useful in this paradigm, which
> might be true on Posix platforms (specifically GNU/Linux), but is not
> at all guaranteed elsewhere.  For example, Windows lacks gettimeofday
> altogether and the emulation we use (from libiberty) has 1-sec(!)
> resolution.  By contrast, it _is_ possible on Windows to measure
> intervals with sub-millisecond resolution.
>
> IOW, if we want an interval timing abstraction, let's have an API for
> that, instead of exposing the implementation which might make no sense
> on some platforms.

It's not possible to implement gettimeofday on windows with better
accuracy?  A quick search suggests it is possible.
gettimeofday is pretty simple and standard,
inventing something new has its own disadvantages.

>
>> +If set to a nonzero value, @value{GDBN} will display how much time it
>>  took to execute each command, following the command's own output.
>> -The time is not printed for the commands that run the target, since
>> -there's no mechanism currently to compute how much time was spend
>> -by @value{GDBN} and how much time was spend by the program been debugged.
>> -it's not possibly currently
>
> I'm not sure we should remove that remark, because what it says is
> still true, even after your changes.

The part about time not being printed for commands that run the target
is not true.
Does the part about there being no mechanism to compute how much time
was spent by the inferior really add anything of value?
[Plus it may be true for some configurations and not true for others.
It doesn't really add anything useful so I've opted for KISS and not
making a claim that isn't necessarily true.]
The last part is an incomplete sentence (and bad grammer to boot :-)).

>> +Both cpu time and wallclock time are printed.
>
> "CPU" in caps, or maybe "@sc{cpu}" (look at the PDF to decide which
> one you like best).
>
>> +Note that the cpu time printed is for @value{GDBN} only, it does not include
>> +the execution time of the inferior.
>
> Ditto.
>
> Thanks.
>