From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15531 invoked by alias); 7 Jan 2015 18:21:56 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 15427 invoked by uid 89); 7 Jan 2015 18:21:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mtaout28.012.net.il Received: from mtaout28.012.net.il (HELO mtaout28.012.net.il) (80.179.55.184) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 07 Jan 2015 18:21:53 +0000 Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NHT00M00JU7XU00@mtaout28.012.net.il> for gdb-patches@sourceware.org; Wed, 07 Jan 2015 20:19:47 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NHT00NY2K8ZM300@mtaout28.012.net.il>; Wed, 07 Jan 2015 20:19:47 +0200 (IST) Date: Wed, 07 Jan 2015 18:21:00 -0000 From: Eli Zaretskii Subject: Re: [PATCH] Speed up "gdb -tui" output In-reply-to: To: Doug Evans Cc: palves@redhat.com, gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83k30y78ol.fsf@gnu.org> References: <83zj9v7urq.fsf@gnu.org> <54AD4E22.1010106@redhat.com> X-IsSubscribed: yes X-SW-Source: 2015-01/txt/msg00127.txt.bz2 > Date: Wed, 7 Jan 2015 10:00:32 -0800 > From: Doug Evans > Cc: Eli Zaretskii , gdb-patches > > > - /* 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. Obviously, Someone(TM) relied on the fact that on Unix curses writes to stdout. There are many such places in the code, not only in TUI. > [There's another one in the file as well.] There are many. > So, yeah, it seems like gdb_flush for tui needs to do a wrefresh > (for gdb_stdout/stderr (/stdlog?)) At least, see my other message. And it should treat them differently, since their buffering is different, and the rest of GDB relies on that a lot. And tui_puts currently doesn't know which stream it serves. > Do we need to do gdb_flush (gdb_stdout) if c == '\n'? As I explained, this is not enough. > Normally in curses line buffering doesn't make any sense. ??? The whole point of this discussion is to introduce some kind of buffering to avoid terribly slow performance in TUI mode. > One paints the window and then does a refresh. Except that for the command window, there's no such thing as "paint the window", AFAICS. Various parts of GDB write out various text strings whenever they feel like. You don't have a single point where you can tell the window is done. Currently, we simply refresh every character. My original suggestion to use a newline as such a point was an attempt to find an easy solution, and we already know why that is not good enough. > 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 to continue, ..." prompt. Yes, of course. And this is part of the problem that needs to be solved. > 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. It doesn't. Stuff just scrolls off the screen and is lost forever. > And therefore, I think we don't need to do any call to > gdb_flush here. Could be missing something though. Where's "there"?