From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#66020: (bug#64735 spin-off): regarding the default for read-process-output-max Date: Thu, 21 Sep 2023 20:54:30 +0300 Message-ID: <83f3d122-f11a-d0b7-60c6-9b0c4812cd4d@gutov.dev> References: <8334zmtwwi.fsf@gnu.org> <83tts0rkh5.fsf@gnu.org> <831qf3pd1y.fsf@gnu.org> <28a7916e-92d5-77ab-a61e-f85b59ac76b1@gutov.dev> <83sf7jnq0m.fsf@gnu.org> <5c493f86-0af5-256f-41a7-7d886ab4c5e4@gutov.dev> <83ledanvzw.fsf@gnu.org> <83r0n2m7qz.fsf@gnu.org> <26afa109-9ba3-78a3-0e68-7585ae8e3a19@gutov.dev> <83il8dna30.fsf@gnu.org> <83bke5mhvs.fsf@gnu.org> <83a5tmk79p.fsf@gnu.org> <937d9927-506f-aa36-94e9-3cceb8f629dd@gutov.dev> <83zg1hay6q.fsf@gnu.org> <451d6012-e5ab-df6c-50e3-dac20b91781c@gutov.dev> <58e9135f-915d-beb9-518a-e814ec2a0c5b@gutov.dev> <834jjnacpc.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10322"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Cc: 66020@debbugs.gnu.org, monnier@iro.umontreal.ca, stefankangas@gmail.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Sep 21 19:55:03 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 1qjNtG-0002MX-1y for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 21 Sep 2023 19:55:02 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qjNt8-0008EU-Aj; Thu, 21 Sep 2023 13:54:54 -0400 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 1qjNt6-0008EE-Fo for bug-gnu-emacs@gnu.org; Thu, 21 Sep 2023 13:54:52 -0400 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 1qjNt6-00037y-86 for bug-gnu-emacs@gnu.org; Thu, 21 Sep 2023 13:54:52 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qjNtG-0004DK-AL for bug-gnu-emacs@gnu.org; Thu, 21 Sep 2023 13:55:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 21 Sep 2023 17:55:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66020 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 66020-submit@debbugs.gnu.org id=B66020.169531889316180 (code B ref 66020); Thu, 21 Sep 2023 17:55:02 +0000 Original-Received: (at 66020) by debbugs.gnu.org; 21 Sep 2023 17:54:53 +0000 Original-Received: from localhost ([127.0.0.1]:34783 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qjNt6-0004Cu-NY for submit@debbugs.gnu.org; Thu, 21 Sep 2023 13:54:53 -0400 Original-Received: from out4-smtp.messagingengine.com ([66.111.4.28]:45323) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qjNt2-0004Cc-BL for 66020@debbugs.gnu.org; Thu, 21 Sep 2023 13:54:51 -0400 Original-Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 1469D5C01C8; Thu, 21 Sep 2023 13:54:33 -0400 (EDT) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 21 Sep 2023 13:54:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm1; t= 1695318873; x=1695405273; bh=q1B7TLI6SOwqcxTBfNXZje7JR5MuPKu9Rsq YHLY9Bow=; b=Gjyf+JcEN2jtTsyOQwAJd984QkCTXjQYvs/g80wrB4fSio67C2C XI9p2fU7c+4NAoX9NVoyjmKfjglAyt2DqiTpsWrPjzrPjX4iu+iSEaeQEu7IHcbf yKJZEcgmJ80g8TWYIWKXyb9ydKl/GeeQSk382ZgjgleQZj3XHBJiXcZL8Fogz1yJ mCBLiyy36ud5GYQlxgVnRR+WMXCHFq6eHjeT42dup7K5SYyP7fxEp+yvDyaiMgTu Sfb56hk4nzJO4T1OWR/8d6H+vRrXyCzYzhvcZDlLrL4+rJ7VejLEfu8BpLtynSzN NGCWxFCTqcEyZXd/KI+J6CrwUdSBFYh6CIQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1695318873; x=1695405273; bh=q1B7TLI6SOwqcxTBfNXZje7JR5MuPKu9Rsq YHLY9Bow=; b=AfMxk7UTLymPFy1xqGzx6Lsr7R1+JG1NeyDcKqyepTLpVMwxoqZ N81RVu0r99x0OSmR3JS8wWk3xJZCe3QY0J4PALnvSPF+b7iexVnVxyppO3ENQHMK P6+oHEW0GFX/Vr0MtlwBXzcI1Saj6mJvlVcKdOmvX+rz+YcC0GhvePG8tmqFRTZf nlwvJVzHdEvABTlG8xByErWGWmeUDQGqHHFSg2LTmwrNooVzzP/Q6uwtZc7o9YLD RcaXd505Nm8BGGZ8zWlqNtV0gDyLk3FYSGmewMsNcCsLRgCqzdUbu2R3BN2Gjl55 PNM+RcgAwK+OhjFI26wqyi9+DFN57Nnsstw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudekiedguddukecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttdefjeenucfhrhhomhepffhm ihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrg htthgvrhhnpefhuedtkeevgeegteetkeefjeffgeduudduhfeuveelfedtffffgeegiedv vdejleenucffohhmrghinhepghhnuhdrohhrghenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpegumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 21 Sep 2023 13:54:31 -0400 (EDT) Content-Language: en-US In-Reply-To: <834jjnacpc.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:271013 Archived-At: On 21/09/2023 16:16, Eli Zaretskii wrote: >> Date: Thu, 21 Sep 2023 15:20:57 +0300 >> Cc: Eli Zaretskii, Stefan Kangas, >> 66020@debbugs.gnu.org >> From: Dmitry Gutov >> >> On 21/09/2023 05:36, Stefan Monnier wrote: >>>> make_process), although I had to use a value produced by make_uninit_string: >>>> apparently simply storing a char* field inside a managed structure creates >>>> problems for the GC and early segfaults. Anyway, the result was slightly >>> That should depend on*where* you put that field. Basically, it has to >>> come after: >>> >>> /* The thread a process is linked to, or nil for any thread. */ >>> Lisp_Object thread; >>> /* After this point, there are no Lisp_Objects. */ >>> >>> since all the words up to that point will be traced by the GC (and >>> assumed to be Lisp_Object fields). >> Ah, thanks. That calls for another try. >> >> ...still no improvement, though no statistically significant slowdown >> either this time. > Why did you expect a significant improvement? No need to be surprised, I'm still growing intuition for what is fast and what is slow at this level of abstraction. > Allocating and freeing > the same-size buffer in quick succession has got to be optimally > handled by modern malloc implementations, so I wouldn't be surprised > by what you discover. There should be no OS calls, just reuse of a > buffer that was just recently free'd. The overhead exists, but is > probably very small, so it is lost in the noise. There are context switches after 'read_process_output' exits (control is returned to Emacs's event loop, the external process runs again, we wait on it with 'select'), it might not be there later, especially outside of the lab situation where we benchmark just single external process. So I don't know. I'm not majorly concerned, of course, and wouldn't be at all, if not for the previously recorded minor degragation with larger buffers in the longer-running session (last table in https://debbugs.gnu.org/66020#10).