From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30215 invoked by alias); 7 Jan 2015 18:00:38 -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 30191 invoked by uid 89); 7 Jan 2015 18:00:36 -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-ob0-f182.google.com Received: from mail-ob0-f182.google.com (HELO mail-ob0-f182.google.com) (209.85.214.182) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 07 Jan 2015 18:00:34 +0000 Received: by mail-ob0-f182.google.com with SMTP id wo20so4268634obc.13 for ; Wed, 07 Jan 2015 10:00:33 -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=r3ZN8Krtn8t6Mue4BrNYeI1JIwz7IOwrY7NvO1HfnQA=; b=LHaRR3i1YO6w60oUPvkLfBOHvWIEYKpKywaUh3lcpFkFz07XFDweToPjchJ61a4GPE fFpdWl6ig6DhuADiBCNlQzf3mTjB4wyEaqSLqtj3qmpOtK7aUYxcsENABs6gaDcDgo+b PrX0TvX/7PkMv960XlQDqtUZ69uthEGA41qJvWv6i9CSBWdp7eDHCmN9JBN+Sboei+/i q6CdwjPXG7GjektITmU7D80ZR14mtb8j4FfKuo+B/H+5NnXQiaeUKse8aLukqaablG6d R4XaxBrtquf+V7OlaqTsKoAMLjHYdykVch++vvKpOiaC1/YY/cZo/xddYPmisD6BVjZI HVkQ== X-Gm-Message-State: ALoCoQkHxNh/nMq3iiyU28PjP464v4L3xQKyguwXiYRNke6vtH1b2jLgVzAIDnuv0J1pRi1zR5mu MIME-Version: 1.0 X-Received: by 10.60.63.109 with SMTP id f13mr2893164oes.27.1420653632970; Wed, 07 Jan 2015 10:00:32 -0800 (PST) Received: by 10.182.222.98 with HTTP; Wed, 7 Jan 2015 10:00:32 -0800 (PST) In-Reply-To: <54AD4E22.1010106@redhat.com> References: <83zj9v7urq.fsf@gnu.org> <54AD4E22.1010106@redhat.com> Date: Wed, 07 Jan 2015 18:00:00 -0000 Message-ID: Subject: Re: [PATCH] Speed up "gdb -tui" output From: Doug Evans To: Pedro Alves Cc: Eli Zaretskii , gdb-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-01/txt/msg00124.txt.bz2 On Wed, Jan 7, 2015 at 7:17 AM, Pedro Alves wrote: > On 01/06/2015 06:37 PM, Doug Evans wrote: > >> Having written all that, asking the caller to know to do >> wrefresh at the needed times could be onerous. >> One thing that occurs to me is that gdb does do things like: >> >> Reading symbols from foo ... (work work work) done. >> And if I do that on my standard monster benchmark (fortunately >> I keep a ready-to-use copy lying around for experiments like this :-)) >> I see a long pause before "done." is printed. >> >> And lo and behold, if I apply your patch I see this: >> >> bash$ gdb -tui >> (gdb) file foo >> >> At this point I've hit return but I don't see anything printed. >> >> pause pause pause >> >> and then finally I see all the output: >> >> Reading symbols from foo...done. >> mumble ... >> (gdb) > > Since stdout is line buffered by default (on Unix), if this is > working when the TUI is disabled, then it must be because there's > explicit gdb_flush(gdb_stdout) after "Reading symbols from foo..." > is printed, right? > > Isn't the issue then that the TUI's implementation of > gdb_flush (tui/tui-file.c) should be doing whatever it > needs to flush the output? Should it be calling wrefresh > if the file is gdb_stdout? If we do that, and change tui_puts like: > > - /* 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. [There's another one in the file as well.] There's a comment at the top of tui-io.c mentioning readline needs some work w.r.t. stdout. I don't know off hand if removing the fflush (stdout) will break anything, but obviously in an ideal world it shouldn't be there. So, yeah, it seems like gdb_flush for tui needs to do a wrefresh (for gdb_stdout/stderr (/stdlog?)) I did some experimentation with pagination and "set height". pagination does work, at least a little. [The more I look into tui sources, and the more I play with tui, the lower the bar I have for what I expect to work ...] Do we need to do gdb_flush (gdb_stdout) if c == '\n'? Normally in curses line buffering doesn't make any sense. One paints the window and then does a refresh. 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. 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. My impression is it doesn't. And therefore, I think we don't need to do any call to gdb_flush here. Could be missing something though.