From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6156 invoked by alias); 7 Jan 2015 19:16:04 -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 6069 invoked by uid 89); 7 Jan 2015 19:16:03 -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-f49.google.com Received: from mail-oi0-f49.google.com (HELO mail-oi0-f49.google.com) (209.85.218.49) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 07 Jan 2015 19:16:01 +0000 Received: by mail-oi0-f49.google.com with SMTP id a141so4225144oig.8 for ; Wed, 07 Jan 2015 11:16:00 -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=QEg9KDT+YI/uw3ZGmC3RFWhe6bCFCNrMFfVfgJhXb/s=; b=NqPGKyWJYRcOTMUTUAiqWmO40gJvEgKTvtvdJ6qoMlfk6tTL2K00zrCOA94INdsihQ 7BWgxGdFaVS0F5jOqRReg/7Bb7nkFm8xkmB/t3bWar+HHmsAh4nw08dADBCbzmGCw/64 cI5HORG3gw47L8tTsExE/hU1FZHgbvVez5VdXraUjC9+Vchho8w1V1E7y5vLFm9NbGv/ ywgVJJXOhVN683Hy+fmDPtjA4n5vLw5ROLwjAYIoFSEywBF5erBDyBw+Ab3xqE+8Vtuf t8dPumTmXdbxlKh6lS2B5CgPY7ikXXusamJtCqkXB3UdnvNaALsvFGUvzNPQa11BWhp+ tiGw== X-Gm-Message-State: ALoCoQkk3ihHxpHLAhlruG2f3oEELr7DglTpK4cYtSftbWT+imV6rR1OOGyCW8K4Dai07Nc6waF5 MIME-Version: 1.0 X-Received: by 10.60.131.203 with SMTP id oo11mr3130865oeb.15.1420658159885; Wed, 07 Jan 2015 11:15:59 -0800 (PST) Received: by 10.182.222.98 with HTTP; Wed, 7 Jan 2015 11:15:59 -0800 (PST) In-Reply-To: <83fvbm784e.fsf@gnu.org> References: <83zj9v7urq.fsf@gnu.org> <54AD4E22.1010106@redhat.com> <83mw5u79t7.fsf@gnu.org> <83fvbm784e.fsf@gnu.org> Date: Wed, 07 Jan 2015 19:16: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/msg00136.txt.bz2 On Wed, Jan 7, 2015 at 10:34 AM, Eli Zaretskii wrote: >> Date: Wed, 7 Jan 2015 10:09:03 -0800 >> From: Doug Evans >> Cc: Pedro Alves , gdb-patches >> >> >> Should it be calling wrefresh if the file is gdb_stdout? >> > >> > Only if that stream is a real file, not a string or whatever else we >> > support in ui-file. >> >> tui_file_flush only gets called for tui files > > That's not really true, as you yourself point out: > >> Though I see tui also has its own ui file strings (tui_sfileopen). >> That can go I think. > > I don't see how it could go: it's used. Can't it be replaced with mem_fileopen? Maybe I'm missing something. >> >> 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? >> > >> > No, it's not enough. There's also gdb_stderr and gdb_stdlog, at >> > least. (tui_puts doesn't get the stream as its argument, so it >> > doesn't really know which stream it is serving.) I'm trying to make >> > heads or tails out of this, but I'm not there yet. >> >> Sure, but it does suggest tui_puts is the wrong place to do >> any kind of flushing/refreshing. > > How else can you emulate the unbuffered nature of gdb_stderr and the > line-buffered nature of gdb_stdout, for example? The GDB application > code implicitly expects that. If one wants to restrict the problem to just gdb_stderr vs gdb_stdout (which is insufficient, since gdb_stdout gets unfiltered output), but for discussion's sake ... The tui to_puts method, tui_file_fputs, knows what the stream is.