This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] MI: new timing command


 > > >> > But as a last resort it returns elapsed time which would be wrong.
 > > >> 
 > > >> You keep saying this but I don't see why.  Why is it wrong?  On every
 > > >> platform where we can do it, we'll print usage; on platforms where we
 > > >> can't do it, the odds are pretty good that the OS isn't aggressively
 > > >> scheduling other tasks in while we're running, so wall time is pretty
 > > >> close to right.
 > > > 
 > > > I agree completely.
 > > 
 > > Is this important? This timing is entirely for diagnostic purposes, 
 > > so why try to make it work on every possible platform. We need to document
 > > that -enable-timing may fail, and that's it.
 > 
 > The point is to use get_run_time() from -liberty and never worry about
 > portability again.

Let's be realistic.  This isn't a command for general users of GDB, it isn't
even a command for general users of frontends to GDB.  It's a command for
developers of frontends to GDB which currently means just myself and Vladimir,
and maybe a couple of others like Bob Rossi and Alain Magloire.

I'm not familiar with get_run_time but I'm sure we all know getrusage through
the time shell command.  If the frontend appears to be slow I can see if that's
due to MI or other things running on my system.  I'm not sure that I can do
that with get_run_time.  I would like to start with getrusage and then when
there are hoards of developers rushing to develop frontends for GDB using
MI on Windows, I'll be happy to accommodate them.


-- 
Nick                                           http://www.inet.net.nz/~nickrob


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]