From: Eli Zaretskii <eliz@gnu.org>
To: Doug Evans <dje@google.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFA, doc RFA] Include wallclock time in "maint time" output.
Date: Tue, 20 Sep 2011 07:19:00 -0000 [thread overview]
Message-ID: <E1R5uSD-0003ho-IM@fencepost.gnu.org> (raw)
In-Reply-To: <CADPb22R9ocuaKYqvABFapetE-MhhGLWLZmmH-ffgQ8WXZipFDQ@mail.gmail.com> (message from Doug Evans on Mon, 19 Sep 2011 23:08:52 -0700)
> Date: Mon, 19 Sep 2011 23:08:52 -0700
> From: Doug Evans <dje@google.com>
> Cc: gdb-patches@sourceware.org
>
> > 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.]
It sounds like it would be a good idea to mention these use cases in
the manual.
> It's not possible to implement gettimeofday on windows with better
> accuracy?
It is easy to do that with 10ms resolution, but not below that. Below
that, AFAIK only interval measurements are "easy" on Windows.
> gettimeofday is pretty simple and standard,
> inventing something new has its own disadvantages.
I disagree, but I can live with that.
> >> +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.
The CPU time still accounts for GDB only, right? It sounds like we
interpret this sentence differently, so perhaps it should be reworded
rather than being deleted.
> Does the part about there being no mechanism to compute how much time
> was spent by the inferior really add anything of value?
It explains the meaning of the times we print, IMO. If someone saw
the need to tell that at some point, I tend to honor that.
next prev parent reply other threads:[~2011-09-20 7:09 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-20 5:32 Doug Evans
2011-09-20 5:42 ` Eli Zaretskii
2011-09-20 7:09 ` Doug Evans
2011-09-20 7:19 ` Eli Zaretskii [this message]
2011-09-20 15:20 ` Eli Zaretskii
2011-11-03 23:18 ` Doug Evans
2011-11-04 9:01 ` Eli Zaretskii
2011-11-04 16:46 ` Doug Evans
2011-10-03 19:11 ` Tom Tromey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E1R5uSD-0003ho-IM@fencepost.gnu.org \
--to=eliz@gnu.org \
--cc=dje@google.com \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox