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

Doug Evans
2015-01-07T19:30:41Z

On Wed, Jan 7, 2015 at 11:20 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Wed, 7 Jan 2015 11:08:41 -0800
>> From: Doug Evans <dje@google.com>
>> Cc: gdb-patches <gdb-patches@sourceware.org>
>>
>> On Wed, Jan 7, 2015 at 10:30 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> > The problem is not Windows per se, it's the Windows console driver
>> > implemented as part of ncurses.
>> >
>> >> So one way to go, and again, this is just a possibility,
>> >> is to not send tui_puts a character at a time.
>> >
>> > This means a major redesign of how ui-file and friends work, much more
>> > than the energy and time I have to spend on this issue.
>>
>> Depends on how one approaches it.
>
> If you have ideas how to do that without a major effort, please tell.
> I was talking based on several hours of staring at that stuff, but
> perhaps I missed something.

I can't promise to have a patch ready before 7.9, but I'll put it
on my todo list.

>> Note that while we do explicitly call *_unfiltered with single characters,
>> unfiltered output is not in itself broken up into single characters.
>
> Not sure what you mean by that. fputs_maybe_filtered, which is the
> workhorse of most of the output functions, explicitly writes out the
> stuff it gets one character at a time, by calling fputc_unfiltered.
> How's that not breaking output?

fputs_maybe_filtered is the workhorse for filtered output, and
it early exists for a number of things, like stream != gdb_stdout.
Most unfiltered output goes straight to fputs_unfiltered (which is the
wrapper around the ui-file to_fputs method).
I see there is fputstr{,n}_unfiltered which does things a character
at a time but it looks like it is only used by MI.