This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Speed up "gdb -tui" output
- From: Doug Evans <dje at google dot com>
- To: Eli Zaretskii <eliz at gnu dot org>
- Cc: Pedro Alves <palves at redhat dot com>, gdb-patches <gdb-patches at sourceware dot org>
- Date: Wed, 7 Jan 2015 11:15:59 -0800
- Subject: Re: [PATCH] Speed up "gdb -tui" output
- Authentication-results: sourceware.org; auth=none
- References: <83zj9v7urq dot fsf at gnu dot org> <CADPb22Q7oD3K-dYkngEPDBbV++mLCKifTEmvJczQ=0h2FX0yXA at mail dot gmail dot com> <54AD4E22 dot 1010106 at redhat dot com> <83mw5u79t7 dot fsf at gnu dot org> <CADPb22QqTE+yq9RSRmvBiu0tdy++8S40D8xzKi6k8nLYmiN48g at mail dot gmail dot com> <83fvbm784e dot fsf at gnu dot org>
On Wed, Jan 7, 2015 at 10:34 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Wed, 7 Jan 2015 10:09:03 -0800
>> From: Doug Evans <dje@google.com>
>> Cc: Pedro Alves <palves@redhat.com>, gdb-patches <gdb-patches@sourceware.org>
>>
>> >> Should it be calling wrefresh if the file is gdb_stdout?
>> >
>> > Only if that stream is a real file, not a string or whatever else we
>> > support in ui-file.
>>
>> tui_file_flush only gets called for tui files
>
> That's not really true, as you yourself point out:
>
>> Though I see tui also has its own ui file strings (tui_sfileopen).
>> That can go I think.
>
> I don't see how it could go: it's used.
Can't it be replaced with mem_fileopen?
Maybe I'm missing something.
>> >> If we do that, and change tui_puts like:
>> >>
>> >> - /* We could defer the following. */
>> >> - wrefresh (w);
>> >> - fflush (stdout);
>> >> + if (c == '\n')
>> >> + gdb_flush (gdb_stdout);
>> >>
>> >> would it work?
>> >
>> > No, it's not enough. There's also gdb_stderr and gdb_stdlog, at
>> > least. (tui_puts doesn't get the stream as its argument, so it
>> > doesn't really know which stream it is serving.) I'm trying to make
>> > heads or tails out of this, but I'm not there yet.
>>
>> Sure, but it does suggest tui_puts is the wrong place to do
>> any kind of flushing/refreshing.
>
> How else can you emulate the unbuffered nature of gdb_stderr and the
> line-buffered nature of gdb_stdout, for example? The GDB application
> code implicitly expects that.
If one wants to restrict the problem to just gdb_stderr vs gdb_stdout
(which is insufficient, since gdb_stdout gets unfiltered output),
but for discussion's sake ...
The tui to_puts method, tui_file_fputs, knows what the stream is.