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

[Eli Zaretskii <eliz@gnu.org>]

> 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.

> [There's another one in the file as well.]

There are many.

> 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.

> Do we need to do gdb_flush (gdb_stdout) if c == '\n'?

As I explained, this is not enough.

> 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.

> 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.  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.

> 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.

> 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.

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

Where's "there"?