From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24743 invoked by alias); 6 Jan 2015 20:54:06 -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 24734 invoked by uid 89); 6 Jan 2015 20:54:05 -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-f174.google.com Received: from mail-ob0-f174.google.com (HELO mail-ob0-f174.google.com) (209.85.214.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 06 Jan 2015 20:54:04 +0000 Received: by mail-ob0-f174.google.com with SMTP id uz6so100125obc.5 for ; Tue, 06 Jan 2015 12:54:02 -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=5ZG9+vinhYRE3SsepXpek3PlScKBuMpgATvdS3CkCh8=; b=AcHF6FPU+UP/yyQbLhOe+5N+vieKZ/1OF0tZGNzFsMe2HfeG0Yubp0xQ3+lYSyMLGw D3Ui+k0ounY3U2Zt8e+KqUOFu3LtvnHD62WXvVJMeGh4aVTyGzvTmxKRJw8NsAXTvPCM cjExBhE9nyKTATxCnkHDdhHWw85ZNoTP1DWu2ErANpJO+MiTusqmsKkWYV6J8n+46U4x YoXK7jqKEevJ1zBzHJJvt6YM7mDIUkMQh9RHD5cJjYSDC5M6T9TeUPU8vJF28Wt0bfQ1 vwIq9NZ8Pw/YWYrZnEjEqdrCLXGerKqQVG2YMHetBjoaQsKaddhn7syUo6so5NrttsFC bGqg== X-Gm-Message-State: ALoCoQkW4Yq0vX9YwzQPMd8lHjmFZob8adsjSOBhW1QzqRTvoDEHVe/qOgDysaCvrZWydyFqyXQO MIME-Version: 1.0 X-Received: by 10.202.226.2 with SMTP id z2mr10895531oig.64.1420577642343; Tue, 06 Jan 2015 12:54:02 -0800 (PST) Received: by 10.182.222.98 with HTTP; Tue, 6 Jan 2015 12:54:02 -0800 (PST) In-Reply-To: <83sifn7mpt.fsf@gnu.org> References: <83zj9v7urq.fsf@gnu.org> <83sifn7mpt.fsf@gnu.org> Date: Tue, 06 Jan 2015 20:54: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/msg00086.txt.bz2 On Tue, Jan 6, 2015 at 11:06 AM, Eli Zaretskii wrote: >> Date: Tue, 6 Jan 2015 10:37:13 -0800 >> From: Doug Evans >> Cc: gdb-patches >> >> 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) > > If this is the only place where this matters, we could break that line > in two: > > Reading symbols from foo... > Done reading symbols from foo. > > Or maybe we could also call wrefresh when we see 3 consecutive dots, > assuming that these are the cases where a prolonged operation is under > way. Not adding a newline after the three dots does lead to other problems: the code is assuming other code won't output a newline. It may be uncommon but it still happens. Thus one could make the case that outputting anything like this without a newline is something to be avoided. OTOH, I wouldn't want to preclude it. Keying off of "..." is a possibility, we could make it a formal convention. One could make the case that it's too hacky though, I don't have a strong opinion. tui_puts would have to maintain global state to track what it's been previously sent, which one would like to avoid if possible (though I see tui_puts already does that to handle annotations). I don't know if there are other places in gdb that output something (sans newline), do some work, and then output the rest of the line (setting aside debugging output). They would all have to be audited and maybe changed. > >> Another possibility would be to do the string -> char -> string >> processing differently. String printing utilities could accumulate >> what they want to print and send the output in chunks instead >> of characters. >> Then tui_puts could get real strings instead of always getting >> { char, '\0' }, and maybe that would be enough. > > This will hit the same problem: how to know when to stop accumulating > and flush it out. What I'm saying is tui_puts would still call wrefresh unconditionally. This is no different than your patch, conceptually, except that it'd be up to higher layers to not send tui_puts a character at a time for the common case of outputting strings. We send output a character at a time in part to support lines_per_page, chars_per_line, and wrap_column, relying on character-at-a-time buffering to save us. Alas for windows that doesn't apparently doesn't work (yay windows). So one way to go, and again, this is just a possibility, is to not send tui_puts a character at a time. Is it possible to fix windows? If the bug really is there ...