Re: [PATCH] Speed up "gdb -tui" output

[Doug Evans <dje@google.com>]

On Wed, Jan 7, 2015 at 10:22 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Wed, 7 Jan 2015 10:00:32 -0800
>> From: Doug Evans <dje@google.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>, gdb-patches <gdb-patches@sourceware.org>
>>
>> >  -  /* We could defer the following.  */
>> >  -  wrefresh (w);
>> >  -  fflush (stdout);
>> >  +   if (c == '\n')
>> >  +    gdb_flush (gdb_stdout);
>> >
>> > would it work?
>>
>> TBH I'm not entirely sure why the fflush (stdout) is there.
>
> Obviously, Someone(TM) relied on the fact that on Unix curses writes
> to stdout.  There are many such places in the code, not only in TUI.

Except that (and I'm relying on memory here so heads up),
curses programs don't need or do fflush (stdout).  Even Unix ones.

>> So, yeah, it seems like gdb_flush for tui needs to do a wrefresh
>> (for gdb_stdout/stderr (/stdlog?))
>
> At least, see my other message.  And it should treat them differently,
> since their buffering is different, and the rest of GDB relies on that
> a lot.  And tui_puts currently doesn't know which stream it serves.

It's easy enough to make tui_puts know what stream it's serving though,
so I'm not worried about that.

>> Normally in curses line buffering doesn't make any sense.
>
> ??? The whole point of this discussion is to introduce some kind of
> buffering to avoid terribly slow performance in TUI mode.

Yes, I know.

For reference sake, by "line buffering" I'm referring to stdio
line buffering.  Curses is different.  It handles buffering differently.
One writes to various windows/frames/whatever (I can't remember
this part of curses terminology), that can be anywhere on the screen,
or even write directly to specific rows/columns,
and then when one does a refresh curses optimizes the "transmission"
of characters to the #rows-by-#columns grid of characters that the
user sees.  There is no "line" as far as the physical connection
to the screen goes.  Way back when, ttys and 1200 baud connections
made this optimization important. :-)

>
>> One paints the window and then does a refresh.
>
> Except that for the command window, there's no such thing as "paint
> the window", AFAICS.

By "paint the window" I mean writing something into that part of the
screen.

> Various parts of GDB write out various text
> strings whenever they feel like.  You don't have a single point where
> you can tell the window is done.  Currently, we simply refresh every
> character.  My original suggestion to use a newline as such a point
> was an attempt to find an easy solution, and we already know why that
> is not good enough.

There's no "single" point, but OTOH there aren't many points either.

>> We want to add scrolling of the command line window on
>> top of that, but if the intent is for that to be handled by
>> gdb's standard set height mechanism (which could use
>> some TLC w.r.t. TUI), then the screen will be refreshed
>> at the "Type <return> to continue, ..." prompt.
>
> Yes, of course.  And this is part of the problem that needs to be
> solved.

Except that scrolling isn't straightforward in curses land.
Do we "scroll" unfiltered output (that hasn't gone through
the paginator) ?

>> I don't off hand know if TUI tries to give the user the
>> impression of scrolling if the user sets the height
>> to be larger than the physical command line window.
>
> It doesn't.  Stuff just scrolls off the screen and is lost forever.

Yeah, so we need a scroll buffer for TUI if we want
to solve that.

>> And therefore, I think we don't need to do any call to
>> gdb_flush here.  Could be missing something though.
>
> Where's "there"?

tui_puts, at least in its current implementation.
It's just an implementation detail though, so
depending on how we fix things that can change.