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

[Doug Evans <dje@google.com>]

On Wed, Jan 7, 2015 at 7:17 AM, Pedro Alves <palves@redhat.com> wrote:
> On 01/06/2015 06:37 PM, Doug Evans wrote:
>
>> Having written all that, asking the caller to know to do
>> wrefresh at the needed times could be onerous.
>> One thing that occurs to me is that gdb does do things like:
>>
>> Reading symbols from foo ... (work work work) done.
>> And if I do that on my standard monster benchmark (fortunately
>> I keep a ready-to-use copy lying around for experiments like this :-))
>> I see a long pause before "done." is printed.
>>
>> And lo and behold, if I apply your patch I see this:
>>
>> bash$ gdb -tui
>> (gdb) file foo<ret>
>>
>> At this point I've hit return but I don't see anything printed.
>>
>> pause pause pause
>>
>> and then finally I see all the output:
>>
>> 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?
>
> 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?  Should it be calling wrefresh
> if the file is gdb_stdout?  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?

TBH I'm not entirely sure why the fflush (stdout) is there.
[There's another one in the file as well.]
There's a comment at the top of tui-io.c mentioning readline
needs some work w.r.t. stdout.

I don't know off hand if removing the fflush (stdout) will break anything,
but obviously in an ideal world it shouldn't be there.

So, yeah, it seems like gdb_flush for tui needs to do a wrefresh
(for gdb_stdout/stderr (/stdlog?))

I did some experimentation with pagination and "set height".
pagination does work, at least a little.
[The more I look into tui sources, and the more I play with tui,
the lower the bar I have for what I expect to work ...]

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

Normally in curses line buffering doesn't make any sense.
One paints the window and then does a refresh.
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.
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.
My impression is it doesn't.
And therefore, I think we don't need to do any call to
gdb_flush here.  Could be missing something though.