From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4911 invoked by alias); 20 Sep 2011 06:09:16 -0000 Received: (qmail 4901 invoked by uid 22791); 20 Sep 2011 06:09:14 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (74.125.121.67) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 20 Sep 2011 06:08:58 +0000 Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7]) by smtp-out.google.com with ESMTP id p8K68uEr018548 for ; Mon, 19 Sep 2011 23:08:56 -0700 Received: from qyg14 (qyg14.prod.google.com [10.241.82.142]) by hpaq7.eem.corp.google.com with ESMTP id p8K67wjs002757 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 19 Sep 2011 23:08:55 -0700 Received: by qyg14 with SMTP id 14so163558qyg.9 for ; Mon, 19 Sep 2011 23:08:55 -0700 (PDT) Received: by 10.224.217.194 with SMTP id hn2mr315673qab.11.1316498934111; Mon, 19 Sep 2011 23:08:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.217.194 with SMTP id hn2mr315647qab.11.1316498932181; Mon, 19 Sep 2011 23:08:52 -0700 (PDT) Received: by 10.224.80.149 with HTTP; Mon, 19 Sep 2011 23:08:52 -0700 (PDT) In-Reply-To: References: <20110920041137.A67D02461A0@ruffy.mtv.corp.google.com> Date: Tue, 20 Sep 2011 07:09:00 -0000 Message-ID: Subject: Re: [RFA, doc RFA] Include wallclock time in "maint time" output. From: Doug Evans To: Eli Zaretskii Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-09/txt/msg00372.txt.bz2 On Mon, Sep 19, 2011 at 10:31 PM, Eli Zaretskii 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. =A0Are 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. =A0What you suggest is to call gettimeofday > twice and then subtract the values. =A0But 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. =A0For example, Windows lacks gettimeofday > altogether and the emulation we use (from libiberty) has 1-sec(!) > resolution. =A0By 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 >> =A0took 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 debugge= d. >> -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 in= clude >> +the execution time of the inferior. > > Ditto. > > Thanks. >