Stefan Kangas <stefankangas@HIDDEN>
to control <at> debbugs.gnu.org.
Full text available.Received: (at 75574) by debbugs.gnu.org; 2 Mar 2025 03:53:06 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 01 22:53:06 2025 Received: from localhost ([127.0.0.1]:49369 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1toaO1-00080u-LF for submit <at> debbugs.gnu.org; Sat, 01 Mar 2025 22:53:05 -0500 Received: from mail-ed1-x533.google.com ([2a00:1450:4864:20::533]:42304) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <stefankangas@HIDDEN>) id 1toaNz-0007zu-7f for 75574 <at> debbugs.gnu.org; Sat, 01 Mar 2025 22:53:04 -0500 Received: by mail-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-5e4ce6e3b8cso4578752a12.1 for <75574 <at> debbugs.gnu.org>; Sat, 01 Mar 2025 19:53:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740887577; x=1741492377; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=31VKElxShqZ29kzgT/3Jv7G6ldmI0EP8GihWuV330YM=; b=Bm1KursDYUlccuxQevH9wCMGxchJftbNxDx4oh6xPeckt2LUIZy7mDMOXI3pMlzmNi ntfKIJ/W9cutNm2eg8NSkMYTpzMSDJAv/0ug8rpfFWrZxlqRDqYiRnlyJQFebrea//nb AMHpiWGxZwBUY3J2VNrcUvM5Kft0auhrFRu33ze+DspZu0qzyz1+cnm7ADkWj9Fam6lx tuavB+IyWnljEg0gejpgslIFhS0D8uIo8I0U/HFmtwSnrAd2E6xPuCBQ8EQMWaBmOjjO EDdK2aI/OIYdQTDwZwG3TrGooqDxKHgHJGmZgdRYfqgrsMZvwHON4JLXTo/t0GR0gSC2 iIGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740887577; x=1741492377; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=31VKElxShqZ29kzgT/3Jv7G6ldmI0EP8GihWuV330YM=; b=F0k1dvMsc7WQDVoDD10k3WLFQzIVQOSZL2qSP4JPsvZYJnUaJpib3ffSPw66G8Aeg0 dMXDm+iP+fjwnxjVKDQea//OIlNFYhM6ANQKuiKt0tsNql9yStWVgoq8lIa9j4VO4o+E vPI063SzoLEO7Ao7TeKa0ao9iOk/NMcCjeRP6Hi1hPPZaoHhiuI4t1scryNwnm2BNRCi Tz/L9+6x2lq5mFADqY+Nn+x+9fSHihBAFpjgqxhUviJJDfUr67+dWE0/QnfnOVgcSiS7 h5Fk4uTA+Mlj2a3p6c8Ucqn4AFoM7K5ZV54mCiLrLsuTcshh0NoyQ7ujTq88lvWjjnC+ U4+Q== X-Forwarded-Encrypted: i=1; AJvYcCULtA1AmPe+8lKocK6vqEDHKlFhljD/XzNhMW1+ESEjt71jg5Cerwy5BXmfeEcLZRNF+e9dpg==@debbugs.gnu.org X-Gm-Message-State: AOJu0YyCJ4TT9cNPKsyE9fS+f7g8Em33Py/T0TCmMrUdlyozGBjDC/Zu ye7aJqjEBtqg7NYw7E4wUg3vHUpMf69HuD3QNKWqi34L3LqzH8NHk8hGXyPZTcsLFZzFwuelGfl abhBnnlNGvCY6e3DnDBek0T6INDI= X-Gm-Gg: ASbGnctvv//XP5SihRIpAu3q6uLoZM25g5wW8iErQKlwu+3je4O26/thQYHzBjKQho/ klHAgsGqIFu4jkN8UgLWYnoZzNBw9xZ+GJFxBj4lx8JbGCy2pey1NmeE00yYo6C2MKlkc3n3S/j pm1hw+CVhK41782rMvnM5SiXup0g== X-Google-Smtp-Source: AGHT+IHOYMsgiYUyZuHkJnezP9kCl9hMJY6Kn6DguYhH2I/ywYNMNO8bZTcervAb+WPzT7gJQNvAWIFCNnHvGOe0e7M= X-Received: by 2002:a50:d708:0:b0:5e0:7df0:6623 with SMTP id 4fb4d7f45d1cf-5e4bfaa6cbdmr13025436a12.6.1740887577173; Sat, 01 Mar 2025 19:52:57 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Sat, 1 Mar 2025 19:52:56 -0800 From: Stefan Kangas <stefankangas@HIDDEN> In-Reply-To: <86cyfoy8n0.fsf@HIDDEN> References: <895A7BFF-F56E-4C62-B6B7-A3BE83D32556@HIDDEN> <86zfjsjf7j.fsf@HIDDEN> <E3E2AE74-4B75-4888-8AE2-A4F9100B51E9@HIDDEN> <86msfsjckr.fsf@HIDDEN> <CADwFkmmMuQ_XV-1+YVQMTLvuOVmT4f3UHKiTxf5ZY5-Fnsipwg@HIDDEN> <86cyfoy8n0.fsf@HIDDEN> MIME-Version: 1.0 Date: Sat, 1 Mar 2025 19:52:56 -0800 X-Gm-Features: AQ5f1JqNiG_oltL89h4JI_gJ1juLBOfhDF-2uFDTGibzxcUr9dMD1aFN8vi3_BU Message-ID: <CADwFkmnTrCZRTjzGAfduu28yQEh+E6wjNnXtqKJXJHeTOxKj_A@HIDDEN> Subject: Re: bug#75574: Adaptive read buffering is a pessimization To: Eli Zaretskii <eliz@HIDDEN> Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75574 Cc: dancol@HIDDEN, 75574 <at> debbugs.gnu.org, eggert@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Eli Zaretskii <eliz@HIDDEN> writes: >> From: Stefan Kangas <stefankangas@HIDDEN> >> Date: Mon, 10 Feb 2025 12:55:58 -0800 >> Cc: eggert@HIDDEN, 75574 <at> debbugs.gnu.org >> >> Does anyone object to also marking the variable as obsolete now? > > I suggest to first see if the new setting causes any problems. > There's no need to hurry with obsoleting it, since un-obsoleting is a > problematic process, as we've seen in the past. OK, let's wait a bit. I'm leaving this bug open as a reminder to consider doing this later.
bug-gnu-emacs@HIDDEN:bug#75574; Package emacs.
Full text available.Received: (at 75574) by debbugs.gnu.org; 11 Feb 2025 12:21:37 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 11 07:21:37 2025 Received: from localhost ([127.0.0.1]:54744 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1thpGi-0003uo-N0 for submit <at> debbugs.gnu.org; Tue, 11 Feb 2025 07:21:37 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:35030) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1thpGf-0003uW-Ad for 75574 <at> debbugs.gnu.org; Tue, 11 Feb 2025 07:21:34 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1thpGY-0005tO-ND; Tue, 11 Feb 2025 07:21:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=bl6vI4jG9DDD7MvIYCR/43ee0rbXtoKkmHcfuHNs8yc=; b=K69x2Ko6JQ28 wlctLHkIzhzVpa5aEpwWOrIRBXxeWdogw8GiqK8b3x70M+oE+m/SVyoBoE/x5iQrga64sAkcbuTJ+ snbrAtRVTPnSs9K5fdSQZRfAVyW0XLCVuUjSdN2K6uU6uYRnJ/wuL/UT6i4+WjoEk5qGjwiOgsFDX 1XzRvA4v+XnQ/TOsaKQGkgOqCDIt10CTwRu7qFjFwqyUHTRgIRJCU87ZVs3mpYXi3/xej6kcSEM/L 9Q+fkQJnKqZyU9F4c1gB3GmMGHXsbIdyfLPe9tV/XRSS7eBks29re1QQ1UzqzcEAOI6ZtJ+S0VNpE w1dhROVOnoFA61Ob5lnZBA==; Date: Tue, 11 Feb 2025 14:21:23 +0200 Message-Id: <86cyfoy8n0.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Kangas <stefankangas@HIDDEN> In-Reply-To: <CADwFkmmMuQ_XV-1+YVQMTLvuOVmT4f3UHKiTxf5ZY5-Fnsipwg@HIDDEN> (message from Stefan Kangas on Mon, 10 Feb 2025 12:55:58 -0800) Subject: Re: bug#75574: Adaptive read buffering is a pessimization References: <895A7BFF-F56E-4C62-B6B7-A3BE83D32556@HIDDEN> <86zfjsjf7j.fsf@HIDDEN> <E3E2AE74-4B75-4888-8AE2-A4F9100B51E9@HIDDEN> <86msfsjckr.fsf@HIDDEN> <CADwFkmmMuQ_XV-1+YVQMTLvuOVmT4f3UHKiTxf5ZY5-Fnsipwg@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75574 Cc: dancol@HIDDEN, 75574 <at> debbugs.gnu.org, eggert@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Stefan Kangas <stefankangas@HIDDEN> > Date: Mon, 10 Feb 2025 12:55:58 -0800 > Cc: eggert@HIDDEN, 75574 <at> debbugs.gnu.org > > Eli Zaretskii <eliz@HIDDEN> writes: > > > It wasn't just a good idea, though. It actually helped fix some use > > cases. > > There is evidence that setting it to nil solved issues too: > > https://yhetil.org/emacs-bugs/13742752.post@HIDDEN/ > https://yhetil.org/emacs-bugs/1B2B2EF98D55CB41BD16F13B18B9B0080303EF48@HIDDEN/ > https://yhetil.org/emacs-bugs/873an4b898.fsf__5420.00031932748$1214278000$gmane$org@HIDDEN/ > > > We could begin by setting this variable nil by default and see if > > someone complains. If enough time has passed without any complaints, > > we could then consider actually removing the feature. > > So let's do that. I have now changed the default on master (commit > 8437bcb5c96). > > Does anyone object to also marking the variable as obsolete now? I suggest to first see if the new setting causes any problems. There's no need to hurry with obsoleting it, since un-obsoleting is a problematic process, as we've seen in the past.
bug-gnu-emacs@HIDDEN:bug#75574; Package emacs.
Full text available.Received: (at 75574) by debbugs.gnu.org; 10 Feb 2025 21:49:28 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 10 16:49:28 2025 Received: from localhost ([127.0.0.1]:52793 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1thbeh-0005Kw-Op for submit <at> debbugs.gnu.org; Mon, 10 Feb 2025 16:49:28 -0500 Received: from dancol.org ([2600:3c01:e000:3d8::1]:54356) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <dancol@HIDDEN>) id 1thbed-0005Kk-AD for 75574 <at> debbugs.gnu.org; Mon, 10 Feb 2025 16:49:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID: References:In-Reply-To:Subject:CC:To:From:Date:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=ctFCakl3LJpzYpu3ffuuW1MtY7sGCuibNgDKA08oXuY=; b=K0sPeOqz2AfJfpPnL9rvVUpd6C FkEo887EqiR0QzpUbdDT4RhkD0j2AoBG35NqGT0/HpSaR5IezeOysw+mTapPF7vK4cSxaEERWBOKM 36YjJKSqWA7Uw7K4yC686mZb1U1JB8o23CBLyIQ0wGBFVWVuUay6KOBmu7ZnHO095Xqb48vFmPvW4 7wIOMrOk5sV0t2ucT8B47uPTa92gEeqqQCep5Zk6XCFc34wOp30dlfpHkILCBPYiXAbRhtYaiVkJ0 oDqAus6vneHJHhuvRhujinsK1871zZHFAiXk/L2na6zFH0KTVpTjpkFnznyRx3g2SuSTDfVR2SZN2 WJ+ADS4w==; Received: from [2600:1010:b057:e5c0:0:42:cdde:4d01] (port=38478 helo=[IPv6:::1]) by dancol.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from <dancol@HIDDEN>) id 1thbeV-0001Ue-0L; Mon, 10 Feb 2025 16:49:15 -0500 Date: Mon, 10 Feb 2025 13:49:14 -0800 From: Daniel Colascione <dancol@HIDDEN> To: Stefan Kangas <stefankangas@HIDDEN>, Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#75574: Adaptive read buffering is a pessimization User-Agent: K-9 Mail for Android In-Reply-To: <CADwFkmmMuQ_XV-1+YVQMTLvuOVmT4f3UHKiTxf5ZY5-Fnsipwg@HIDDEN> References: <895A7BFF-F56E-4C62-B6B7-A3BE83D32556@HIDDEN> <86zfjsjf7j.fsf@HIDDEN> <E3E2AE74-4B75-4888-8AE2-A4F9100B51E9@HIDDEN> <86msfsjckr.fsf@HIDDEN> <CADwFkmmMuQ_XV-1+YVQMTLvuOVmT4f3UHKiTxf5ZY5-Fnsipwg@HIDDEN> Message-ID: <6802F8B6-764D-4214-BA94-2ED9722D79F1@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.1 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On February 10, 2025 12:55:58 PM PST, Stefan Kangas <stefankangas@HIDDEN> wrote: >Eli Zaretskii <eliz@HIDDEN> writes: > >> It wasn't just a good idea, though. It actually helped fix some use >> ca [...] Content analysis details: (1.1 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 0.0 LOTS_OF_MONEY Huge... sums of money 1.1 MONEY_NOHTML Lots of money in plain text X-Debbugs-Envelope-To: 75574 Cc: eggert@HIDDEN, 75574 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: 0.1 (/) On February 10, 2025 12:55:58 PM PST, Stefan Kangas <stefankangas@gmail=2E= com> wrote: >Eli Zaretskii <eliz@gnu=2Eorg> writes: > >> It wasn't just a good idea, though=2E It actually helped fix some use >> cases=2E > >There is evidence that setting it to nil solved issues too: > >https://yhetil=2Eorg/emacs-bugs/13742752=2Epost@talk=2Enabble=2Ecom/ >https://yhetil=2Eorg/emacs-bugs/1B2B2EF98D55CB41BD16F13B18B9B0080303EF48@= FFBRUE001=2Ecfmu=2Ecorp=2Eeurocontrol=2Eint/ >https://yhetil=2Eorg/emacs-bugs/873an4b898=2Efsf__5420=2E00031932748$1214= 278000$gmane$org@ambire=2Elocaldomain/ > >> We could begin by setting this variable nil by default and see if >> someone complains=2E If enough time has passed without any complaints, >> we could then consider actually removing the feature=2E > >So let's do that=2E I have now changed the default on master (commit >8437bcb5c96)=2E > >Does anyone object to also marking the variable as obsolete now? Thanks=2E I hadn't gotten around to doing it myself=2E Obsolete sounds goo= d to me=2E
bug-gnu-emacs@HIDDEN:bug#75574; Package emacs.
Full text available.Received: (at 75574) by debbugs.gnu.org; 10 Feb 2025 20:56:11 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 10 15:56:11 2025 Received: from localhost ([127.0.0.1]:52722 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1thap8-0002uh-OO for submit <at> debbugs.gnu.org; Mon, 10 Feb 2025 15:56:11 -0500 Received: from mail-ed1-x535.google.com ([2a00:1450:4864:20::535]:47211) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <stefankangas@HIDDEN>) id 1thap3-0002u1-6w for 75574 <at> debbugs.gnu.org; Mon, 10 Feb 2025 15:56:08 -0500 Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-5de4a8b4f86so5375512a12.2 for <75574 <at> debbugs.gnu.org>; Mon, 10 Feb 2025 12:56:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1739220959; x=1739825759; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=eSX+RZiaUjlCd7kuhMTNN6/Ij0xTkZMT4N9zcjf2U98=; b=iKHYqvwtAqCwAYp1IhGFHLVV0m+v5oJUEwzhJk5KsSA4bSd3yT7A7zmC7SFepwlX1W OUL6M+6vGMYRqeKISTNdm6IhtJrf27fN9c88cEeKNJ12pz9y+eNiixIR4dWtc5S7QmqR 4RlM0oTkVrJV7GWnQtdDOjKKFhPLDFGy6aTYmrTn2CHv2IL22NC1EG4HUiWVg2hPAMWC b2+HsvWaFmxAHbrKyW2ZjwAV1Rqp2z8Iqr08topM6KGl1HuPmybKI5w3Wa3745kdQoNU C844bF576NZSRj3IlQMRPd3+HavKMIy6Fi4coElY/R4mM2D1fVJtUdytE0Axc2FwWdzO K6NA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739220959; x=1739825759; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=eSX+RZiaUjlCd7kuhMTNN6/Ij0xTkZMT4N9zcjf2U98=; b=qM/L13PL1PpyUxYW4qtOITbYMTAw7mxFxMDy19T0rW7X7A49ZQcAbTtfxodvYGKqbG dApz5VpGGwq9676EjO8pJsI7uVhU6Qq/O78+W2KzyU5/X6CfmRKOMvAN+HQy5gHl6u+H BSkhKP+ziCDuliCCfUISr9sriewwNldlsWCv0TGaCa580A7n5nRtZWjVvI/pCX52si1v hi5eAp1KQ5WK9I4OjD/eRrSOh/iwihCtDeqWSRrND2xsFYwHq1N0M4o38JKXdUXxSRlY vtMxNJrozqtNUGN8Sq9y4ia6OIiP05Y5fB6IzLDpzdB0cFc+SVK6/+kkAOke+nnrKBCM 4M/A== X-Forwarded-Encrypted: i=1; AJvYcCVSd0VQ8HeGzGXfS2jJtVg4c7auZR52n64/sObxS8GGGIzWOpVAOzKotT+3znPU4whkve7qxQ==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwZKjBEazqgklqIciswMe76hT3HgW/4mzlDIuNfArngwuR8jKgm /LEAm1Q5BY7+rDOlqSv8x13iwFzWyBrmCyhVaW1eWxLAF9Bts/5R2GHTPg3D66G1e4ilXLfvRyy 829WZOvshDO5YSdWnI8WqIYvGflQ= X-Gm-Gg: ASbGncuYzJi/1UHYOu0zxCVqdnoMwn9Nr+9/se93ppYNBYpCtOWQieucc+XVnjn+b2M pyrJU/G5uSGqyExGHMz9LcD6RpjKBsPdChiRcyOMf5WcRnaqRV2iNTUyEEiq8RUdTDlEYoEACPQ == X-Google-Smtp-Source: AGHT+IHEi2Wb02rr1PlKBqpouCYpvJChceGhCVQofwxa3F0/kpXhqc9lbbx+xqZG92Tx8orSU5R6Oiw1xUR6+4hcKRI= X-Received: by 2002:a50:aad0:0:b0:5db:da94:6e7e with SMTP id 4fb4d7f45d1cf-5de45073388mr11932655a12.24.1739220958673; Mon, 10 Feb 2025 12:55:58 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Mon, 10 Feb 2025 12:55:58 -0800 From: Stefan Kangas <stefankangas@HIDDEN> In-Reply-To: <86msfsjckr.fsf@HIDDEN> References: <895A7BFF-F56E-4C62-B6B7-A3BE83D32556@HIDDEN> <86zfjsjf7j.fsf@HIDDEN> <E3E2AE74-4B75-4888-8AE2-A4F9100B51E9@HIDDEN> <86msfsjckr.fsf@HIDDEN> MIME-Version: 1.0 Date: Mon, 10 Feb 2025 12:55:58 -0800 X-Gm-Features: AWEUYZnyW3kie2Rz1hu81mLdpnXJrCfim1JhyCtDd0ilo4FxzLkW1ZmPFltH6zg Message-ID: <CADwFkmmMuQ_XV-1+YVQMTLvuOVmT4f3UHKiTxf5ZY5-Fnsipwg@HIDDEN> Subject: Re: bug#75574: Adaptive read buffering is a pessimization To: Eli Zaretskii <eliz@HIDDEN>, Daniel Colascione <dancol@HIDDEN> Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75574 Cc: eggert@HIDDEN, 75574 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Eli Zaretskii <eliz@HIDDEN> writes: > It wasn't just a good idea, though. It actually helped fix some use > cases. There is evidence that setting it to nil solved issues too: https://yhetil.org/emacs-bugs/13742752.post@HIDDEN/ https://yhetil.org/emacs-bugs/1B2B2EF98D55CB41BD16F13B18B9B0080303EF48@HIDDEN/ https://yhetil.org/emacs-bugs/873an4b898.fsf__5420.00031932748$1214278000$gmane$org@HIDDEN/ > We could begin by setting this variable nil by default and see if > someone complains. If enough time has passed without any complaints, > we could then consider actually removing the feature. So let's do that. I have now changed the default on master (commit 8437bcb5c96). Does anyone object to also marking the variable as obsolete now?
bug-gnu-emacs@HIDDEN:bug#75574; Package emacs.
Full text available.Received: (at 75574) by debbugs.gnu.org; 15 Jan 2025 15:56:21 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 15 10:56:21 2025 Received: from localhost ([127.0.0.1]:58401 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tY5kj-0007sm-8n for submit <at> debbugs.gnu.org; Wed, 15 Jan 2025 10:56:21 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:40368) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tY5kh-0007sR-99 for 75574 <at> debbugs.gnu.org; Wed, 15 Jan 2025 10:56:20 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1tY5kZ-0003fM-Ow; Wed, 15 Jan 2025 10:56:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=FKTM3tMjx+WXnWqlU1LtwAXX2ZZ4/2jEFhsxOyQ+brk=; b=g6V7oJaMBIFZ V6QJ/nyEFXTE1oURwH3VXTp41nUagRXJgQ+2nE4G5Vk79B1PFpdFBvPtvAYchtQ5CZdwExIkrA36q sj3xnIWINiY11ZPgGRQUGGZrhm0iE+ybJd3fi6MCPKHNqojcEHF6XPdeSDXJRKWXB00EKoRn+tOF9 FkdFgrNMcd+euiru5TlqqW1Zf+9gDmfpezX4wpCPIN+MXp++J9iaqjKoNAFmjLxi7JLtr5xWiXlCG ySld5tQ6/Qzd4c/A1hPCvF/sG/1MuZLjQzUAFbMPTyPdVdNhjCkQAZXGQMZ21TKcGUI/vrFq50sQi 00hyWaWBwIzAmsK47oJMFQ==; Date: Wed, 15 Jan 2025 17:56:04 +0200 Message-Id: <86msfsjckr.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Daniel Colascione <dancol@HIDDEN> In-Reply-To: <E3E2AE74-4B75-4888-8AE2-A4F9100B51E9@HIDDEN> (message from Daniel Colascione on Wed, 15 Jan 2025 07:37:10 -0800) Subject: Re: bug#75574: Adaptive read buffering is a pessimization References: <895A7BFF-F56E-4C62-B6B7-A3BE83D32556@HIDDEN> <86zfjsjf7j.fsf@HIDDEN> <E3E2AE74-4B75-4888-8AE2-A4F9100B51E9@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75574 Cc: eggert@HIDDEN, 75574 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Wed, 15 Jan 2025 07:37:10 -0800 > From: Daniel Colascione <dancol@HIDDEN> > CC: 75574 <at> debbugs.gnu.org > > > > On January 15, 2025 6:59:12 AM PST, Eli Zaretskii <eliz@HIDDEN> wrote: > >> Date: Tue, 14 Jan 2025 21:42:13 -0800 > >> From: Daniel Colascione <dancol@HIDDEN> > >> > >> The adaptive read buffering code delays reads in the hope that we can read in buffer chunks if we wait a > >> little bit between reads from a process producing a lot of output. Sounds good. Doesn't work. The attempted > >> optimization reduces performance in various scenarios and causes an 8x regression in performance for me > >> in flows involving mixtures of big and small reads. > >> > >> With adaptive reading, we increase the read delay every time we get a short read and decrease it when we > >> get a full buffer of data or do a write. The problem is 1) that there are legitimate flows involving long > >> sequences of reads without an intervening write and 2) reads (especially from PTYs) may *never* report a > >> full buffer because the kernel limits the maximum read size no matter how big the backlog is. (For example, > >> the Darwin kernel limits PTY (and presumably TTY in general?) reads to 1024 bytes, but the default Emacs > >> read size is 64k, so we never recognize a signal that we should reduce the read delay. > >> > >> I'd suggest just deleting the feature. It's not worth the complexity and edge cases, IMHO. > >> > >> If that's not an option, I'd suggest detecting bulk flows by doing a zero timeout select() after we're tempted to > >> increase the delay and actually increasing the delay only when that select times out. > >> > >> Just tweaking the maximum read size probably isn't a good idea: it's an implementation detail and can > >> change with time and over the types of FD from which we read. > > > >AFAICS, this feature can be disabled by setting > >process-adaptive-read-buffering to the nil value, either globally or > >let-binding it around start-process. Does that solve your problems, > >and if so, can we conclude that Emacs allows both using the feature > >and disabling it. > > Well, I mean, Emacs is free software, so in theory users can disable any bug with enough elbow grease, even ones we don't know about. I have the radical idea that it shouldn't be slow by default and that users shouldn't have to manually disable known bugs. > > >AFAIR, in some situation this was really useful, otherwise we wouldn't > >have set it to t by default. > > Plenty of questionable things sound like good ideas at the time. It wasn't just a good idea, though. It actually helped fix some use cases. > >Or maybe we should introduce a new special value of > >process-adaptive-read-buffering, which would be equivalent to nil when > >reading from PTYs, if that case can never benefit from these delays? > > Even if you were to limit the adaptive reading to pipes and sockets, you'd still have the problem with trying to guess the maximum read size even if you limit the mechanism to pipes. It's just broken. I don't see a reason to continue to maintain the complexity. What are we saving? A few context switches, maybe? Machines are fast enough that we don't need to make a queue form for the sake of batching. I see your point. However, this area is really tricky, and supports many different usage patterns. There are Lisp programs that read relatively small chunks of input from a subprocess, and then there are other programs which read huge amounts of data. I wouldn't risk deciding we have all of them figured out and can conclude they all don't need this. You can try searching the bug tracker for process-adaptive-read-buffering, it will bring up several hits. We could begin by setting this variable nil by default and see if someone complains. If enough time has passed without any complaints, we could then consider actually removing the feature.
bug-gnu-emacs@HIDDEN:bug#75574; Package emacs.
Full text available.Received: (at 75574) by debbugs.gnu.org; 15 Jan 2025 15:37:19 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 15 10:37:19 2025 Received: from localhost ([127.0.0.1]:58354 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tY5SJ-0006yO-8O for submit <at> debbugs.gnu.org; Wed, 15 Jan 2025 10:37:19 -0500 Received: from dancol.org ([2600:3c01:e000:3d8::1]:38310) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <dancol@HIDDEN>) id 1tY5SG-0006yD-S3 for 75574 <at> debbugs.gnu.org; Wed, 15 Jan 2025 10:37:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID: References:In-Reply-To:Subject:CC:To:From:Date:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=AToE9EHEhoWdmnoSATxNx7yYfXHjJtYj29BaVQ2mOV8=; b=G9JkEGfk1yTJB1XvxLNvRXqtqo JiL3ziFcgnkP5JRGRb7oV8O1a4PZVbxw6ENaszJxv4dkvNIoVrDnQf39EsTJoLPe/sHT7YJUukG3C vek94lu1n7TC9YEtECm4YP/zMDrQNlyKmUm3p5QiXgPy/xRVhRe2d/P8N+xXEIxdrPC+UwDeo2C/R zZssR98M8zalxNY7CQSwgZlW9irGTonW00sTXbIOH+kLUG0BxK7oJZOttiJiJLHCxCvnNyvgC8B9u NEUdzmNedmEehogsTFgO6WttY9DCyp8/p0Q3y7gR4G8ZmmnIUT0zobSj76wHre0fhHtd4Y8O5+3VD CcaEkksw==; Received: from [2600:1010:b01b:dc40:0:4f:429c:601] (port=60458 helo=[IPv6:::1]) by dancol.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from <dancol@HIDDEN>) id 1tY5SA-0001t1-2N; Wed, 15 Jan 2025 10:37:10 -0500 Date: Wed, 15 Jan 2025 07:37:10 -0800 From: Daniel Colascione <dancol@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN>, Paul Eggert <eggert@HIDDEN> Subject: Re: bug#75574: Adaptive read buffering is a pessimization User-Agent: K-9 Mail for Android In-Reply-To: <86zfjsjf7j.fsf@HIDDEN> References: <895A7BFF-F56E-4C62-B6B7-A3BE83D32556@HIDDEN> <86zfjsjf7j.fsf@HIDDEN> Message-ID: <E3E2AE74-4B75-4888-8AE2-A4F9100B51E9@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 75574 Cc: 75574 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On January 15, 2025 6:59:12 AM PST, Eli Zaretskii <eliz@gnu=2Eorg> wrote: >> Date: Tue, 14 Jan 2025 21:42:13 -0800 >> From: Daniel Colascione <dancol@dancol=2Eorg> >>=20 >> The adaptive read buffering code delays reads in the hope that we can r= ead in buffer chunks if we wait a >> little bit between reads from a process producing a lot of output=2E So= unds good=2E Doesn't work=2E The attempted >> optimization reduces performance in various scenarios and causes an 8x = regression in performance for me >> in flows involving mixtures of big and small reads=2E >>=20 >> With adaptive reading, we increase the read delay every time we get a s= hort read and decrease it when we >> get a full buffer of data or do a write=2E The problem is 1) that ther= e are legitimate flows involving long >> sequences of reads without an intervening write and 2) reads (especiall= y from PTYs) may *never* report a >> full buffer because the kernel limits the maximum read size no matter h= ow big the backlog is=2E (For example, >> the Darwin kernel limits PTY (and presumably TTY in general?) reads to = 1024 bytes, but the default Emacs >> read size is 64k, so we never recognize a signal that we should reduce = the read delay=2E >>=20 >> I'd suggest just deleting the feature=2E It's not worth the complexity = and edge cases, IMHO=2E >>=20 >> If that's not an option, I'd suggest detecting bulk flows by doing a ze= ro timeout select() after we're tempted to >> increase the delay and actually increasing the delay only when that sel= ect times out=2E >>=20 >> Just tweaking the maximum read size probably isn't a good idea: it's an= implementation detail and can >> change with time and over the types of FD from which we read=2E > >AFAICS, this feature can be disabled by setting >process-adaptive-read-buffering to the nil value, either globally or >let-binding it around start-process=2E Does that solve your problems, >and if so, can we conclude that Emacs allows both using the feature >and disabling it=2E Well, I mean, Emacs is free software, so in theory users can disable any b= ug with enough elbow grease, even ones we don't know about=2E I have the ra= dical idea that it shouldn't be slow by default and that users shouldn't ha= ve to manually disable known bugs=2E >AFAIR, in some situation this was really useful, otherwise we wouldn't >have set it to t by default=2E Plenty of questionable things sound like good ideas at the time=2E >Or maybe we should introduce a new special value of >process-adaptive-read-buffering, which would be equivalent to nil when >reading from PTYs, if that case can never benefit from these delays? Even if you were to limit the adaptive reading to pipes and sockets, you'd= still have the problem with trying to guess the maximum read size even if = you limit the mechanism to pipes=2E It's just broken=2E I don't see a reaso= n to continue to maintain the complexity=2E What are we saving? A few conte= xt switches, maybe? Machines are fast enough that we don't need to make a q= ueue form for the sake of batching=2E
bug-gnu-emacs@HIDDEN:bug#75574; Package emacs.
Full text available.Received: (at 75574) by debbugs.gnu.org; 15 Jan 2025 14:59:26 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 15 09:59:25 2025 Received: from localhost ([127.0.0.1]:58281 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tY4rd-00054y-F0 for submit <at> debbugs.gnu.org; Wed, 15 Jan 2025 09:59:25 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:43048) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tY4rb-00054g-4a for 75574 <at> debbugs.gnu.org; Wed, 15 Jan 2025 09:59:23 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1tY4rV-0002UR-28; Wed, 15 Jan 2025 09:59:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=aiMDBDO493gZ+Z2kWAQRBHydCdUVFH1ezHLU5S8XBQA=; b=KhCq59ZdhNve XUxafJGZw4qKI4eOn0+JO42m51+Bpbd59mC4BMZuFcQ05Fa5h0clv4dqlml4cf7tUIWwxW7JiFCY0 vHl6zaQndHEG9QuUU7vlvgyM61JtEMkOxZqH0x7hEg0Ape3xSBr8B/RgDEXVDzl/RnKdtAAEYksSW uZuBfJUUfoyka6BZnzBxHWieerXTsEwKveQLOUORZKLWLXEjlZ+DaGFtxqwV95HMXge2f0RgueOB0 QpX6XgI9H9/lBMrjx+DQcxlAPa0asYW1y8QZh1pd0wNTSFvgMpsTayOhIxAQpaD2NpAQJhj1ZiV3B Necg9mTUzkj3zHujshEoFw==; Date: Wed, 15 Jan 2025 16:59:12 +0200 Message-Id: <86zfjsjf7j.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Daniel Colascione <dancol@HIDDEN>, Paul Eggert <eggert@HIDDEN> In-Reply-To: <895A7BFF-F56E-4C62-B6B7-A3BE83D32556@HIDDEN> (message from Daniel Colascione on Tue, 14 Jan 2025 21:42:13 -0800) Subject: Re: bug#75574: Adaptive read buffering is a pessimization References: <895A7BFF-F56E-4C62-B6B7-A3BE83D32556@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75574 Cc: 75574 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Tue, 14 Jan 2025 21:42:13 -0800 > From: Daniel Colascione <dancol@HIDDEN> > > The adaptive read buffering code delays reads in the hope that we can read in buffer chunks if we wait a > little bit between reads from a process producing a lot of output. Sounds good. Doesn't work. The attempted > optimization reduces performance in various scenarios and causes an 8x regression in performance for me > in flows involving mixtures of big and small reads. > > With adaptive reading, we increase the read delay every time we get a short read and decrease it when we > get a full buffer of data or do a write. The problem is 1) that there are legitimate flows involving long > sequences of reads without an intervening write and 2) reads (especially from PTYs) may *never* report a > full buffer because the kernel limits the maximum read size no matter how big the backlog is. (For example, > the Darwin kernel limits PTY (and presumably TTY in general?) reads to 1024 bytes, but the default Emacs > read size is 64k, so we never recognize a signal that we should reduce the read delay. > > I'd suggest just deleting the feature. It's not worth the complexity and edge cases, IMHO. > > If that's not an option, I'd suggest detecting bulk flows by doing a zero timeout select() after we're tempted to > increase the delay and actually increasing the delay only when that select times out. > > Just tweaking the maximum read size probably isn't a good idea: it's an implementation detail and can > change with time and over the types of FD from which we read. AFAICS, this feature can be disabled by setting process-adaptive-read-buffering to the nil value, either globally or let-binding it around start-process. Does that solve your problems, and if so, can we conclude that Emacs allows both using the feature and disabling it. AFAIR, in some situation this was really useful, otherwise we wouldn't have set it to t by default. Or maybe we should introduce a new special value of process-adaptive-read-buffering, which would be equivalent to nil when reading from PTYs, if that case can never benefit from these delays?
bug-gnu-emacs@HIDDEN:bug#75574; Package emacs.
Full text available.Received: (at submit) by debbugs.gnu.org; 15 Jan 2025 05:42:29 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 15 00:42:29 2025 Received: from localhost ([127.0.0.1]:56681 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tXwAe-0000WV-Jz for submit <at> debbugs.gnu.org; Wed, 15 Jan 2025 00:42:29 -0500 Received: from lists.gnu.org ([2001:470:142::17]:57496) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <dancol@HIDDEN>) id 1tXwAb-0000WH-IL for submit <at> debbugs.gnu.org; Wed, 15 Jan 2025 00:42:26 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <dancol@HIDDEN>) id 1tXwAW-0008Kn-5Q for bug-gnu-emacs@HIDDEN; Wed, 15 Jan 2025 00:42:20 -0500 Received: from dancol.org ([2600:3c01:e000:3d8::1]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <dancol@HIDDEN>) id 1tXwAT-000167-Uo for bug-gnu-emacs@HIDDEN; Wed, 15 Jan 2025 00:42:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Subject :To:From:Date:Sender:Reply-To:Cc:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive; bh=g2mTjqFQ/lQ6EOhtT5ZAqzimZbzv7Sa7Eo6SQPtZyZA=; b=O 7yaO3h1cLV50XLihMr1BfBN/Em4l6WTUsefA75O+mL6rxXumYT040t8lZ1VZhfOuLmoB/RQoT2cID HmulE6RzKUyuSpQctO7qR7uAej01wlb2UJPyxEi+eiMRIva5n+0M6t3V95BF3m3/MF3sgO8J/sUl2 pLpygnZa0BDaM1g7WKKCRU94/uPraW3YI6lqeeKwmUJEUZ8a1D7xYjkMkQmfBvhU3g45PL5X3jZ07 4xWFhEM2v+fDt0vWGQyMHQ+jROjVT5RQc87L58bQ5HhuXoLoYmnL2Qv1dKa0mPNnV27IsdMifPPNl UnZH/3a2Mifms1XdvvgJsnboEyrk5LEWQ==; Received: from [2600:1010:b01b:dc40:0:4f:429c:601] (port=36120 helo=[IPv6:::1]) by dancol.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from <dancol@HIDDEN>) id 1tXwAP-0008La-0q for bug-gnu-emacs@HIDDEN; Wed, 15 Jan 2025 00:42:13 -0500 Date: Tue, 14 Jan 2025 21:42:13 -0800 From: Daniel Colascione <dancol@HIDDEN> To: bug-gnu-emacs@HIDDEN Subject: Adaptive read buffering is a pessimization User-Agent: K-9 Mail for Android Message-ID: <895A7BFF-F56E-4C62-B6B7-A3BE83D32556@HIDDEN> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=----WJC86OT9YS6QHO8GVCYY2F9V29J17T Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=2600:3c01:e000:3d8::1; envelope-from=dancol@HIDDEN; helo=dancol.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.9 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.1 (/) ------WJC86OT9YS6QHO8GVCYY2F9V29J17T Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The adaptive read buffering code delays reads in the hope that we can read = in buffer chunks if we wait a little bit between reads from a process produ= cing a lot of output=2E Sounds good=2E Doesn't work=2E The attempted optimi= zation reduces performance in various scenarios and causes an 8x regression= in performance for me in flows involving mixtures of big and small reads= =2E With adaptive reading, we increase the read delay every time we get a shor= t read and decrease it when we get a full buffer of data or do a write=2E = The problem is 1) that there are legitimate flows involving long sequences = of reads without an intervening write and 2) reads (especially from PTYs) m= ay *never* report a full buffer because the kernel limits the maximum read = size no matter how big the backlog is=2E (For example, the Darwin kernel li= mits PTY (and presumably TTY in general?) reads to 1024 bytes, but the defa= ult Emacs read size is 64k, so we never recognize a signal that we should r= educe the read delay=2E I'd suggest just deleting the feature=2E It's not worth the complexity and= edge cases, IMHO=2E If that's not an option, I'd suggest detecting bulk flows by doing a zero = timeout select() after we're tempted to increase the delay and actually inc= reasing the delay only when that select times out=2E Just tweaking the maximum read size probably isn't a good idea: it's an im= plementation detail and can change with time and over the types of FD from = which we read=2E ------WJC86OT9YS6QHO8GVCYY2F9V29J17T Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <!DOCTYPE html><html><body><div dir=3D"auto">The adaptive read buffering co= de delays reads in the hope that we can read in buffer chunks if we wait a = little bit between reads from a process producing a lot of output=2E Sounds= good=2E Doesn't work=2E The attempted optimization reduces performance in = various scenarios and causes an 8x regression in performance for me in flow= s involving mixtures of big and small reads=2E<br><br>With adaptive reading= , we increase the read delay every time we get a short read and decrease it= when we get a full buffer of data or do a write=2E=C2=A0 The problem is 1)= that there are legitimate flows involving long sequences of reads without = an intervening write and 2) reads (especially from PTYs) may *never* report= a full buffer because the kernel limits the maximum read size no matter ho= w big the backlog is=2E (For example, the Darwin kernel limits PTY (and pre= sumably TTY in general?) reads to 1024 bytes, but the default Emacs read si= ze is 64k, so we never recognize a signal that we should reduce the read de= lay=2E<br><br>I'd suggest just deleting the feature=2E It's not worth the c= omplexity and edge cases, IMHO=2E<br><br>If that's not an option, I'd sugge= st detecting bulk flows by doing a zero timeout select() after we're tempte= d to increase the delay and actually increasing the delay only when that se= lect times out=2E<br><br>Just tweaking the maximum read size probably isn't= a good idea: it's an implementation detail and can change with time and ov= er the types of FD from which we read=2E<br><br></div></body></html> ------WJC86OT9YS6QHO8GVCYY2F9V29J17T--
Daniel Colascione <dancol@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#75574; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.