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

[Doug Evans <dje@google.com>]

On Tue, Jan 6, 2015 at 11:06 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Tue, 6 Jan 2015 10:37:13 -0800
>> From: Doug Evans <dje@google.com>
>> Cc: gdb-patches <gdb-patches@sourceware.org>
>>
>> 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)
>
> If this is the only place where this matters, we could break that line
> in two:
>
>   Reading symbols from foo...
>   Done reading symbols from foo.
>
> Or maybe we could also call wrefresh when we see 3 consecutive dots,
> assuming that these are the cases where a prolonged operation is under
> way.

Not adding a newline after the three dots does lead to other problems:
the code is assuming other code won't output a newline.  It may be uncommon
but it still happens. Thus one could make the case that outputting anything
like this without a newline is something to be avoided.
OTOH, I wouldn't want to preclude it.

Keying off of "..." is a possibility, we could make it a formal convention.
One could make the case that it's too hacky though, I don't have a
strong opinion.
tui_puts would have to maintain global state to track what it's been previously
sent, which one would like to avoid if possible (though I see tui_puts already
does that to handle annotations).
I don't know if there are other places in gdb that output something
(sans newline),
do some work, and then output the rest of the line (setting aside
debugging output).
They would all have to be audited and maybe changed.

>
>> Another possibility would be to do the string -> char -> string
>> processing differently.  String printing utilities could accumulate
>> what they want to print and send the output in chunks instead
>> of characters.
>> Then tui_puts could get real strings instead of always getting
>> { char, '\0' }, and maybe that would be enough.
>
> This will hit the same problem: how to know when to stop accumulating
> and flush it out.

What I'm saying is tui_puts would still call wrefresh unconditionally.
This is no different than your patch, conceptually, except that
it'd be up to higher layers to not send tui_puts a character at a time for the
common case of outputting strings.

We send output a character at a time in part to support
lines_per_page, chars_per_line, and wrap_column,
relying on character-at-a-time buffering to save us.
Alas for windows that doesn't apparently doesn't work (yay windows).
So one way to go, and again, this is just a possibility,
is to not send tui_puts a character at a time.

Is it possible to fix windows?
If the bug really is there ...