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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 7 Jan 2015 11:30:37 -0800
> From: Doug Evans <dje@google.com>
> Cc: gdb-patches <gdb-patches@sourceware.org>
> 
> I can't promise to have a patch ready before 7.9, but I'll put it
> on my todo list.

Thanks.

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

It is used both for gdb_stdout and for other streams.

> Most unfiltered output goes straight to fputs_unfiltered (which is the
> wrapper around the ui-file to_fputs method).

Once again, I fail to see how this fact, which I certainly noticed
already, helps to solve the problem.  When fputs_maybe_filtered is
called, we have no idea whether the text it gets is complete enough to
flush the stream after we are done with it.  That information is at
higher levels.  So we don't know whether to flush the stream after the
direct call to fputs_unfiltered.

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

Grep for fputs_unfiltered callers, and you will see that there are
much more calls with only 1 or 2 characters.

Anyway, if we want to analyze the current callers and build our
solution on that, we will be limited to what we currently have.  Not
sure if this is good or bad, but that's exactly what I am trying to
do, and I still have some lose ends in the heuristics.

But a general solution is not possible that way, because a general
solution cannot depend on who does or doesn't call certain functions.
That general solution is what looked hard to me.