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: Sat, 29 Jan 2022 17:10:48 +0100 Message-ID: <831e0891-8344-8cae-e0be-5a4c78c2c01c@gmail.com> References: <499ab53f-7c23-b5ed-6105-3072fffb4bfe@gmail.com> <83imbby3yt.fsf@gnu.org> <87czkbg9u7.fsf@gnus.org> <87k0eid2uv.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35833"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 Cc: 44007@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jan 29 17:11:18 2022 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 1nDqJq-0009Do-Ry for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 29 Jan 2022 17:11:18 +0100 Original-Received: from localhost ([::1]:43494 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nDqJp-0000BU-9j for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 29 Jan 2022 11:11:17 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:40930) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nDqJa-0000BI-KC for bug-gnu-emacs@gnu.org; Sat, 29 Jan 2022 11:11:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41639) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nDqJa-0007iP-8W for bug-gnu-emacs@gnu.org; Sat, 29 Jan 2022 11:11:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nDqJZ-0003Yn-UQ for bug-gnu-emacs@gnu.org; Sat, 29 Jan 2022 11:11: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: Sat, 29 Jan 2022 16:11:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 44007 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 44007-submit@debbugs.gnu.org id=B44007.164347265713674 (code B ref 44007); Sat, 29 Jan 2022 16:11:01 +0000 Original-Received: (at 44007) by debbugs.gnu.org; 29 Jan 2022 16:10:57 +0000 Original-Received: from localhost ([127.0.0.1]:34542 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nDqJV-0003YU-I3 for submit@debbugs.gnu.org; Sat, 29 Jan 2022 11:10:57 -0500 Original-Received: from mail-ej1-f49.google.com ([209.85.218.49]:40575) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nDqJT-0003YC-V5 for 44007@debbugs.gnu.org; Sat, 29 Jan 2022 11:10:56 -0500 Original-Received: by mail-ej1-f49.google.com with SMTP id p15so27045164ejc.7 for <44007@debbugs.gnu.org>; Sat, 29 Jan 2022 08:10:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=xxkJH6fZkbng4AhGDaXVIK2QRlOJP6StS14HVdSQ5/M=; b=lmPIy8SWUYaZSJZpojR0VB+MI9UgHt5wyd3tZo1uLXp8swhrVF/juUwb91Vqio30hj U5+HALM+JYvYyrs8QAXH4I5SG4QCYeEm6yU5KYIJvlFxDaaLzreNFSg1/NJ1LDDw1CAD DSE2pNfdIEIp+9Dp2ljg8y4Drm2462XVBT+waYCxlIbaba959WWAqTQn2jPwKvDQNBD6 gJ5auO/Yh0crwviveImgsdJxdfOFophLm1npH08sWhJr3sTjLRl/SiX4fspfoLreazDi D1B06ONERaF5z8EMTWRCJbuoSp8Yuii1g3MShilMcOa3L3HFl+iwnrocpIgnaFsaZMjA Jnug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=xxkJH6fZkbng4AhGDaXVIK2QRlOJP6StS14HVdSQ5/M=; b=f2jL9C6s8JzVAqqCyp/d/DR7CNKfIZaWdKbdeW42m4nByILST8g43HsuhHO1vgf7kW 7aLNfJpnASrOFvIqj9PXgqJlkHhvy54pyQvN4DluotQ9bSpiz6czhpuueHgOz5K39YMF 1ECbfi2iKQtn+v8OXp01M/ICABMhswmxWFVZEQcoxoUCC8Uo1+MXX49zNwKu+BCzmfp+ k5SWH2AYsnYrXw+F3HvQpOpL0ka6KOX4T7U0Rnl9jTSNXvLwdL/SWYM0TKH9sRxBmAAw z/jKnkMX/llTueWWWC5ReX54mgXeS16xuvNjD0kdcBRDOShfpqDosOD/pVcWKvpXf7cH fx/A== X-Gm-Message-State: AOAM533KiwwRG+JOx8iQ8+zAGmU/ADptXAAADohOOa35bJj5DS8RMLnu x6H1J+Voyu1Quzy2L/zIy0U= X-Google-Smtp-Source: ABdhPJz2rCjN19J6vwWGTCl2IiELRsKWZQSII3gQpJrWJj97zG9h62ENOMpVqNRLddIB5Rl5H1lvZQ== X-Received: by 2002:a17:907:3da2:: with SMTP id he34mr11766447ejc.595.1643472650012; Sat, 29 Jan 2022 08:10:50 -0800 (PST) Original-Received: from [192.168.8.4] (netacc-gpn-7-193-112.pool.telenor.hu. [176.77.193.112]) by smtp.gmail.com with ESMTPSA id kw5sm3855086ejc.140.2022.01.29.08.10.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 29 Jan 2022 08:10:49 -0800 (PST) In-Reply-To: <87k0eid2uv.fsf@gnus.org> Content-Language: sv-FI 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" Xref: news.gmane.io gmane.emacs.bugs:225536 Archived-At: It's already fast on your machine, so that's why pressing RET doesn't make a difference. I tried this on a mac with Emacs 27, and it's easily reproduceable (easier than on linux). It seems that on mac, the exact timing of the extra RET doesn't matter. Even if it's halfway printing the numbers, pressing RET speeds up the remaining part. On linux, I have to press RET immediately after executing the command, otherwise it doesn't become faster. But I've found something right now: this issue is dependent on the shell. With zsh, this happens. With bash, it doesn't. Weird. So it seems that zsh sets something which makes this issue to appear. Nevertheless, I think emacs_intr_read() is not ideal, it should handle the case if multiple read() calls needed to gather all the available data (I've been using emacs with my hacky patch for more than a year, I didn't notice any problems with it). On 2022-01-29 15:38, Lars Ingebrigtsen wrote: > "Herman, Géza" writes: > >> How much time does "seq 100000" take for you? Does it use 100% cpu? > emacs -Q > M-x shell > seq 100000 > > takes very little time for me -- perhaps 0.2s? > > If I add a zero, it takes about five seconds, but hitting RET in the > middle doesn't affect the speed. > >> Maybe the OS matters here (how the read() syscall behaves): I'm on >> debian linux (sid). > I'm on Debian/bookworm... >