From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18100 invoked by alias); 7 Jan 2015 18:56:16 -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 18083 invoked by uid 89); 7 Jan 2015 18:56:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mail-oi0-f48.google.com Received: from mail-oi0-f48.google.com (HELO mail-oi0-f48.google.com) (209.85.218.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 07 Jan 2015 18:56:13 +0000 Received: by mail-oi0-f48.google.com with SMTP id u20so4157326oif.7 for ; Wed, 07 Jan 2015 10:56:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=PWevaNuxrn8m7GD8dqVUg9sPMoWYcDEvDZrY/zrjF6U=; b=S2GcBl2RT/1QjO8KFkfoN7RdOIvir2sWVZmAyIunmtXbFgGfqjUXyBRdsI7gKRqizs VOBG2Q9Xz8tptccDKdnv8HG54vgSO7UXlQgG9ny+9Q1hvJWB20cXYoEuK1piWluyVmrn XCiUPEuRdyI1rQ1nmRSCeUEYqzHMyPlehslFuFv9VHQBvuXkn/7O7ppK710zRkhtEh7u s17+unQIBFZxeUDYF73p4IfSqOAKxB/wDatz9REn1H7op/uCAkCunRjl5sp3JESAyRH7 s3NBNkvMuz6RRDGPK0y3vcp+zZ1U37PlDdiN+LsH4fZmjHAmv/99OGs8dvT8h9J6/xW9 IhhA== X-Gm-Message-State: ALoCoQlmrU385TTMhuUkJyK1xN6iZbZq/igfkcN8ChEyMN3aO2d3pjE7iibBogDMXyhAxPZTTVZ0 MIME-Version: 1.0 X-Received: by 10.182.227.161 with SMTP id sb1mr3063232obc.80.1420656971663; Wed, 07 Jan 2015 10:56:11 -0800 (PST) Received: by 10.182.222.98 with HTTP; Wed, 7 Jan 2015 10:56:11 -0800 (PST) In-Reply-To: <83k30y78ol.fsf@gnu.org> References: <83zj9v7urq.fsf@gnu.org> <54AD4E22.1010106@redhat.com> <83k30y78ol.fsf@gnu.org> Date: Wed, 07 Jan 2015 18:56:00 -0000 Message-ID: Subject: Re: [PATCH] Speed up "gdb -tui" output From: Doug Evans To: Eli Zaretskii Cc: Pedro Alves , gdb-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-01/txt/msg00132.txt.bz2 On Wed, Jan 7, 2015 at 10:22 AM, Eli Zaretskii wrote: >> 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. Except that (and I'm relying on memory here so heads up), curses programs don't need or do fflush (stdout). Even Unix ones. >> 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. It's easy enough to make tui_puts know what stream it's serving though, so I'm not worried about that. >> 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. Yes, I know. For reference sake, by "line buffering" I'm referring to stdio line buffering. Curses is different. It handles buffering differently. One writes to various windows/frames/whatever (I can't remember this part of curses terminology), that can be anywhere on the screen, or even write directly to specific rows/columns, and then when one does a refresh curses optimizes the "transmission" of characters to the #rows-by-#columns grid of characters that the user sees. There is no "line" as far as the physical connection to the screen goes. Way back when, ttys and 1200 baud connections made this optimization important. :-) > >> 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. By "paint the window" I mean writing something into that part of the screen. > 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. There's no "single" point, but OTOH there aren't many points either. >> 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. Except that scrolling isn't straightforward in curses land. Do we "scroll" unfiltered output (that hasn't gone through the paginator) ? >> 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. Yeah, so we need a scroll buffer for TUI if we want to solve that. >> And therefore, I think we don't need to do any call to >> gdb_flush here. Could be missing something though. > > Where's "there"? tui_puts, at least in its current implementation. It's just an implementation detail though, so depending on how we fix things that can change.