From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Herman@debbugs.gnu.org, =?UTF-8?Q?G=C3=A9za?= Newsgroups: gmane.emacs.bugs Subject: bug#44007: 26.3; Strange shell mode performance Date: Mon, 06 Nov 2023 18:25:00 +0100 Message-ID: <875y2e22i8.fsf@gmail.com> References: <499ab53f-7c23-b5ed-6105-3072fffb4bfe@gmail.com> <83imbby3yt.fsf@gnu.org> <1cfcee64-0002-dedd-fb8f-528660e7c807@gmail.com> <83v8af2iey.fsf@gnu.org> <87bkc73uk4.fsf@gmail.com> <83jzqv2ezv.fsf@gnu.org> <87zfzrx8hy.fsf@gmail.com> <83h6lz2bei.fsf@gnu.org> <87v8aeyl9v.fsf@gmail.com> <83cywm3jtp.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8890"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 44007@debbugs.gnu.org, Herman =?UTF-8?Q?G=C3=A9za?= To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Nov 06 18:54:02 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1r03nV-00023z-Lh for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 06 Nov 2023 18:54:01 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r03mz-0004Nk-5w; Mon, 06 Nov 2023 12:53:29 -0500 Original-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 ) id 1r03mx-0004MB-6B for bug-gnu-emacs@gnu.org; Mon, 06 Nov 2023 12:53:27 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r03mv-0008Tj-Os for bug-gnu-emacs@gnu.org; Mon, 06 Nov 2023 12:53:25 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1r03nV-0006au-MD for bug-gnu-emacs@gnu.org; Mon, 06 Nov 2023 12:54:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Herman@debbugs.gnu.org, =?UTF-8?Q?G=C3=A9za?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Nov 2023 17:54:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 44007 X-GNU-PR-Package: emacs Original-Received: via spool by 44007-submit@debbugs.gnu.org id=B44007.169929318925259 (code B ref 44007); Mon, 06 Nov 2023 17:54:01 +0000 Original-Received: (at 44007) by debbugs.gnu.org; 6 Nov 2023 17:53:09 +0000 Original-Received: from localhost ([127.0.0.1]:40673 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r03me-0006ZK-O3 for submit@debbugs.gnu.org; Mon, 06 Nov 2023 12:53:09 -0500 Original-Received: from mail-lj1-x22f.google.com ([2a00:1450:4864:20::22f]:45391) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r03mX-0006YZ-6X for 44007@debbugs.gnu.org; Mon, 06 Nov 2023 12:53:07 -0500 Original-Received: by mail-lj1-x22f.google.com with SMTP id 38308e7fff4ca-2c5039d4e88so65708071fa.3 for <44007@debbugs.gnu.org>; Mon, 06 Nov 2023 09:52:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699293137; x=1699897937; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:message-id:in-reply-to:date :subject:cc:to:from:references:from:to:cc:subject:date:message-id :reply-to; bh=sw/lvpPx3qsp89C2Ye1sLR8dfCUUebChks8/kOyxfPw=; b=GRU6H41IBvP9lAlwxxOL9Qjtv7ikk2XosJWYEonqi9gzSBVS0OO+2F6ZrInzyJ8E7y RovAoLItO5x1nNZGhhTaun41TrduAH21op/SCr1+/yWW00jLB8ZbCX8mYykaEHTWa3OV Z9WJcSg/1P+0Rg3o9Gy3H0P+0AujI6vWihOAkyQfnuez2NwAoRY1AwQt1qiiMUFu30yK ZJspwXXstSfYAr+G23sA8YVYFsJavxGQGyuPA+zbQ3OVxDIkg7dfng5oWNsmjNPwVndb tUoHUTUSR/w4mLsdXwBPlo06jhPgQMqtDD163FyhZNxaqhT1Rhn/ae+rgamRseUugzY8 /NWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699293137; x=1699897937; h=content-transfer-encoding:mime-version:message-id:in-reply-to:date :subject:cc:to:from:references:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=sw/lvpPx3qsp89C2Ye1sLR8dfCUUebChks8/kOyxfPw=; b=PL5UvVPBxXDSVycFe+dhR4qO3PyDJqefEBeF1I2FIHX69UKNZ4sTvquQng0eYvMz7o JYRK5ig2oa+TMwvMG+x6w9e3jEmhpcJJmRABe9unDBi/wJbIGVzeB1QcvSHn4yzGaMP8 3ML/bMmq5UcI4qkxq4dnKLEh8hx2DZPc00xpUMbKF1koCZ0dSmp8T6+//CQzTEcaEjYz iLl6KuRCQ5hd5dtKQlldSbR2olEhXVxJQNvUFrXQvPNHJKvuRrbkORNVyPm8IdYJGbOq xHmXHCy1iqQMKkG2d4x9V3SILQPmJ75mYnf1l/Weew4MT6s5BQtYmX+IimGH2Im7peGo JMCQ== X-Gm-Message-State: AOJu0YwCaoluoOyZVt01hEHn0k0y0byzsR98WE+hYqUYjTjGRPCJp7Sq ahimdT7NyVkELiGNjNvX0Y0= X-Google-Smtp-Source: AGHT+IFLQF9c8ZCLJ7G6/N5buLkPCZ1kf31xONU5b63N+LysC65jrKHYmHzimJstpkFteetkRyL0gA== X-Received: by 2002:a2e:b8c9:0:b0:2c6:e5f8:451e with SMTP id s9-20020a2eb8c9000000b002c6e5f8451emr14854531ljp.5.1699293137026; Mon, 06 Nov 2023 09:52:17 -0800 (PST) Original-Received: from localhost (62-77-231-86.static.invitel.hu. [62.77.231.86]) by smtp.gmail.com with ESMTPSA id x17-20020a05600c2d1100b004077219aed5sm12719669wmf.6.2023.11.06.09.52.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Nov 2023 09:52:16 -0800 (PST) In-reply-to: <83cywm3jtp.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:273890 Archived-At: Eli Zaretskii writes: >> From: Herman, G=C3=A9za >> >> I thought that the fd is nonblocking here. > > That doesn't matter here. The problem is not with blocking in=20 > 'read', > the problem is with calling one 'read' after another without=20 > letting > Emacs process the foreground input events. I see. But this loop only loops until either there are no more=20 bytes, or it reaches 'nbytes'. Unless the OS splits the available=20 output into very tiny bits, this shouldn't be a problem. But that=20 would be a bad behavior from the OS part. And even if the data is=20 splitted into tiny bits, the only extra time we pay for is the=20 overhead of the extra read() calls. Maybe for some OS's this can=20 be significant, I'm not sure. For my case, data is only splitted=20 into two pieces (4095 + 1), I don't think this causes any serious=20 problem, even theoretically. But anyways. Before I added this hacky solution to Emacs, I had=20 been an Emacs user for at least 8 years, so I knew how Emacs=20 behaved in certain circumstances. Then I added this hack. Since=20 then I didn't notice any bad behavior or difference, except that=20 I/O become much faster for me. So we have at least one data point=20 that this kind of approach works and doesn't cause any trouble. I know that this is a problem for some people, because when I=20 searched for the cause of this issue, I found multiple reports of=20 shell being slow in Emacs. The last one happened just several days=20 ago on reddit:=20 https://www.reddit.com/r/emacs/comments/17nl7cw/comment/k7tmgz0/?utm_source= =3Dshare&utm_medium=3Dweb2x&context=3D3 (this reddit comment made me to spend some time investigating the=20 issue again), explaining the same exact issue I'm having. But of course, it is possible that this read() loop will cause=20 trouble for someone. But we're not able to tell this until others=20 try this out.