From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 21FEA3858C2C for ; Wed, 2 Feb 2022 16:23:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 21FEA3858C2C Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-552-ENaVu6B6OH-dx6D_JygR1g-1; Wed, 02 Feb 2022 11:23:20 -0500 X-MC-Unique: ENaVu6B6OH-dx6D_JygR1g-1 Received: by mail-wm1-f72.google.com with SMTP id 189-20020a1c02c6000000b0035399bb7e85so2219336wmc.4 for ; Wed, 02 Feb 2022 08:23:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=UImSkTKfuLWqzj6FwDCvB17akwC447ING9oV+9khRG0=; b=piHPTpvbT6DNke/Gu+V6SGZO7GshX3H9Ipt1pMXlynY5OBkIGBzA1ssVZQLaz0qJh6 bvslOLfLm5IL7S18SzSqM56ohGJvebYe4DfI/FfEWx5k8UB9TLbUdbs91AXxTAFaxYhp 8It9XGBq1+PbDZFeSmc+mrir/p9Ab+HfWrp9bu7k+dCq54bk5dK7usujxGEoHm1natgJ ARLDJmDip7SW2XsN8ShmdGtfTOYfkYGTEp9d6G/9fOQZP4PhN/4UFi+ol+OMvZyO92yQ MWh+gcg+T+E+UXXe7KcfDjCOVu+m3gMFb1GehuHxdvf8UknQtHj/vTFxyhuAUmBlynti QikA== X-Gm-Message-State: AOAM531XeMdHkG+tv4U7AIURKFVnPnMrGjXkuP3uaSEkiDL1bKD9S4yD +cWmBUucDngO3/C0HskQB1xGIf8o3pZy/AhB57vfSgM7tMbQ+zdhTK3ie4uz9R/bM1Kp2UNcvKE mQ3B/6584RD4CzpQod0Fnqw== X-Received: by 2002:a5d:64af:: with SMTP id m15mr3983556wrp.478.1643818999305; Wed, 02 Feb 2022 08:23:19 -0800 (PST) X-Google-Smtp-Source: ABdhPJwBBN3uv91T+TbYghpD25+TMIfYvamtJiszTzL7y1aNbTIQjCHVqxxyLrAhTzSbDBoFc1svUw== X-Received: by 2002:a5d:64af:: with SMTP id m15mr3983544wrp.478.1643818999060; Wed, 02 Feb 2022 08:23:19 -0800 (PST) Received: from localhost (host86-140-92-93.range86-140.btcentralplus.com. [86.140.92.93]) by smtp.gmail.com with ESMTPSA id f6sm17680280wrj.26.2022.02.02.08.23.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Feb 2022 08:23:18 -0800 (PST) Date: Wed, 2 Feb 2022 16:23:17 +0000 From: Andrew Burgess To: Simon Marchi Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] gdb: unbuffer all input streams when not using readline Message-ID: <20220202162317.GI425591@redhat.com> References: <20220117164051.1854133-1-aburgess@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Operating-System: Linux/5.8.18-100.fc31.x86_64 (x86_64) X-Uptime: 16:05:46 up 9 days, 6:52, X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2022 16:23:25 -0000 * Simon Marchi via Gdb-patches [2022-01-18 11:26:42 -0500]: > > The change looks ok to me (better than the status quo), given that > correctness is more important than performance. > > I'm just wondering if there's a noticeable performance difference > between having the input buffered vs unbuffered. Calling fgetc with > unbuffered input means we do one syscall per character. With frontends > sending tons of commands, it could possibly affect the responsiveness > and degrade user experience. But it's just a guess, we should be able > to measure it. I'm planning to go ahead and push this patch - I'll give it a couple more days in case someone wants to shout stop! On input performance: - I tested this and was a <1% slow down, which seem acceptable to me, - I notice that readline reads its input one character at a time too, so now our non-readline input is handled the same way, - This function is not used for reading commands from a file (I did a simple test, and didn't hit this function), so shouldn't impact that case at all. On output performance: - The unbuffering will only impact the output file descriptor for the new-ui case, usually, in all other cases, in and out are separate file descriptors, - The new-ui command only really makes sense for spinning up mi interpreters, - The mi interpreter buffers its output in string_files (see mi/mi-out.c), and then writes the output in a single command, so we shouldn't see any change in performance. As this patch fixes a real bug, I think, lets merge this now, and if there's any issues later, we can figure out what to do then. Thanks, Andrew