From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 328 invoked by alias); 7 Jan 2015 20:45:21 -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 316 invoked by uid 89); 7 Jan 2015 20:45:20 -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-f42.google.com Received: from mail-oi0-f42.google.com (HELO mail-oi0-f42.google.com) (209.85.218.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 07 Jan 2015 20:45:17 +0000 Received: by mail-oi0-f42.google.com with SMTP id v63so4619753oia.1 for ; Wed, 07 Jan 2015 12:45:16 -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=PRgQvQ30YPVfAQF5SZS5Q5CCkSCqYU/a1afxECd+mJY=; b=F0P32ycazdTgsVB69VUw2JUEryempk09mDBfKQXC839HJLqtpXcPoik36RNToJhD6T BDic2EydXpCrSuhWvAMwGm4eBzsptOTsI45qzNrpj/S1v3fl20rDNEbLhKtxE7oLDtJn BLETFDsjQhuSx0PmE+heuqjOjs5aPedt8cbcDM+2TW48jVdFy5Kqru752w+9Lo0OJAfb tkCCSmahj7Slq+afEFM6OifPAd0rQsHrGIPf8f5uM246SEwrLfXZonzR629Wa1LzDJW/ N/kTYQByKHEyBPXBjS58npdg3t8RIcakvWTfgsqKjeponlgGIeL0W+9j3HN3csHG1kU6 TMDg== X-Gm-Message-State: ALoCoQnVVxHs/O4oRtHmH7CnRn+h/r4L9Wb9Jbwl9XJp1qEYr2hqG5wPFozMP8G9lyZ+WO22o1e9 MIME-Version: 1.0 X-Received: by 10.202.219.198 with SMTP id s189mr3207098oig.72.1420663515949; Wed, 07 Jan 2015 12:45:15 -0800 (PST) Received: by 10.182.222.98 with HTTP; Wed, 7 Jan 2015 12:45:15 -0800 (PST) In-Reply-To: <837fwy74ny.fsf@gnu.org> References: <83zj9v7urq.fsf@gnu.org> <83sifn7mpt.fsf@gnu.org> <83h9w278a9.fsf@gnu.org> <83bnma75yt.fsf@gnu.org> <837fwy74ny.fsf@gnu.org> Date: Wed, 07 Jan 2015 20:45:00 -0000 Message-ID: Subject: Re: [PATCH] Speed up "gdb -tui" output From: Doug Evans To: Eli Zaretskii Cc: gdb-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-01/txt/msg00143.txt.bz2 On Wed, Jan 7, 2015 at 11:48 AM, Eli Zaretskii wrote: >> Date: Wed, 7 Jan 2015 11:30:37 -0800 >> From: Doug Evans >> Cc: gdb-patches >> >> 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. static void fputs_maybe_filtered (const char *linebuffer, struct ui_file *stream, int filter) { const char *lineptr; if (linebuffer == 0) return; /* Don't do any filtering if it is disabled. */ if (stream != gdb_stdout || !pagination_enabled || batch_flag || (lines_per_page == UINT_MAX && chars_per_line == UINT_MAX) || top_level_interpreter () == NULL || ui_out_is_mi_like_p (interp_ui_out (top_level_interpreter ()))) { fputs_unfiltered (linebuffer, stream); return; } ... } It may be called for other streams, but it early exits with a direct call to fputs_unfiltered if stream != gdb_stdout. I don't know how to say it any plainer than that. > >> 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. My theory is we can punt for streams != gdb_stdout, and for them just always refresh inside calls to tui_file_fputs. And for gdb_stdout rely on calls to gdb_flush to do the refresh. Seems like not that many lines of code to give it a try. > >> 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. I already did, and pointed that out. We don't know yet if they're a problem. Seems like the main source of the problem would be gdb_stdout, so let's try to fix that first and go from there.