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

[Eli Zaretskii <eliz at gnu dot org>]

> Date: Wed, 07 Jan 2015 15:17:54 +0000
> From: Pedro Alves <palves@redhat.com>
> CC: gdb-patches <gdb-patches@sourceware.org>
> 
> > Reading symbols from foo...done.
> > mumble ...
> > (gdb)
> 
> Since stdout is line buffered by default (on Unix), if this is
> working when the TUI is disabled, then it must be because there's
> explicit gdb_flush(gdb_stdout) after "Reading symbols from foo..."
> is printed, right?

Yes.

> Isn't the issue then that the TUI's implementation of
> gdb_flush (tui/tui-file.c) should be doing whatever it
> needs to flush the output?

Maybe.  I already made that change in my sandbox.  Alas, that's just
the tip of the iceberg.  We call single-character output functions,
like putchar and fputc all over the place, implicitly assuming that in
certain cases (e.g., when the stream is stderr), things are unbuffered
and the output appears immediately.  On top of that, functions that
output strings go through single-character output versions, so there's
no easy way of saying on, say, utils.c level whether the character
should or shouldn't appear immediately. It's a terrible mess.

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

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