This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Speed up "gdb -tui" output
- From: Eli Zaretskii <eliz at gnu dot org>
- To: Doug Evans <dje at google dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Wed, 07 Jan 2015 21:48:49 +0200
- Subject: Re: [PATCH] Speed up "gdb -tui" output
- Authentication-results: sourceware.org; auth=none
- References: <83zj9v7urq dot fsf at gnu dot org> <CADPb22Q7oD3K-dYkngEPDBbV++mLCKifTEmvJczQ=0h2FX0yXA at mail dot gmail dot com> <83sifn7mpt dot fsf at gnu dot org> <CADPb22QeiSrzD81kMJeqpnDBrx1DybpbGmHc1r0koGDtqAu8tw at mail dot gmail dot com> <83h9w278a9 dot fsf at gnu dot org> <CADPb22R_=xwonUGJMxJRtAbbK8OcSmU5ojarB=T9wjg9YEtE6Q at mail dot gmail dot com> <83bnma75yt dot fsf at gnu dot org> <CADPb22SvEa8-+y009ET7PQDuYixGEK6LbrJr_pyQ98SfVy_iJg at mail dot gmail dot com>
- Reply-to: Eli Zaretskii <eliz at gnu dot 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.