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#64735: 29.0.92; find invocations are ~15x slower because of ignores Date: Sat, 16 Sep 2023 04:32:26 +0300 Message-ID: References: <83v8e6lyi4.fsf@gnu.org> <35f8b664-0241-9f96-1aa0-20ca51b2d34c@gutov.dev> <59c30342-a7e0-d83b-a128-0faae4cbd633@gutov.dev> <83pm4bi6qa.fsf@gnu.org> <83bkfs2tw5.fsf@gnu.org> <18a0b4d8-32bd-3ecd-8db4-32608a1ebba7@gutov.dev> <83il8lxjcu.fsf@gnu.org> <2e21ec81-8e4f-4c02-ea15-43bd6da3daa7@gutov.dev> <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> 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="36208"; 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: luangruo@yahoo.com, sbaugh@janestreet.com, yantar92@posteo.net, 64735@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Sep 16 03:33:06 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 1qhKBF-0009CF-NJ for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 16 Sep 2023 03:33:06 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qhKB7-0005gH-0q; Fri, 15 Sep 2023 21:32:57 -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 1qhKB5-0005af-Gt for bug-gnu-emacs@gnu.org; Fri, 15 Sep 2023 21:32:55 -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 1qhKB5-0005Zw-8y for bug-gnu-emacs@gnu.org; Fri, 15 Sep 2023 21:32:55 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qhKBB-0000ma-VK for bug-gnu-emacs@gnu.org; Fri, 15 Sep 2023 21:33:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 16 Sep 2023 01:33:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64735 X-GNU-PR-Package: emacs Original-Received: via spool by 64735-submit@debbugs.gnu.org id=B64735.16948279652982 (code B ref 64735); Sat, 16 Sep 2023 01:33:01 +0000 Original-Received: (at 64735) by debbugs.gnu.org; 16 Sep 2023 01:32:45 +0000 Original-Received: from localhost ([127.0.0.1]:45119 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qhKAv-0000m2-9j for submit@debbugs.gnu.org; Fri, 15 Sep 2023 21:32:45 -0400 Original-Received: from wout5-smtp.messagingengine.com ([64.147.123.21]:40381) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qhKAt-0000lp-Bu for 64735@debbugs.gnu.org; Fri, 15 Sep 2023 21:32:44 -0400 Original-Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 82F97320039A; Fri, 15 Sep 2023 21:32:30 -0400 (EDT) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Fri, 15 Sep 2023 21:32:31 -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=fm3; t= 1694827949; x=1694914349; bh=vgS4fKed5c5/cpwdq/ZiBwgaTu0AocRCFwg dZSiZgEI=; b=pELlqjusgus8mghsp8V9lSoMtkdfjTwKKIxE1e2XFzB8qomV5oB paQt1ZqftEDonCaePH7EOl3hFdAJKZug+AKWKqsEgYDdYWiCRJdyLBE48jXCbnfJ vr2qr9nwyg6P8MUkuoSB5w9Y07RTzQIYzBHVcOibKhXcief7wx0RkoVgJyl3BH7D pSnSL7oEatgLhlvbW1B79BuHpD31VCAXl9EZqXYiC1M1HQLeeHq8SwWdsMSJlDKz 9z+FuVcu+jcQqibydJpuSFn4i+90/DJuVLLx0zRfkiB/Ch3wlcDrpHWgec8m5TXx ydcKtNSUgN22ai33Z+EU4ZzX9FsFxppPRig== 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= 1694827949; x=1694914349; bh=vgS4fKed5c5/cpwdq/ZiBwgaTu0AocRCFwg dZSiZgEI=; b=GV4OJuMoagzwEwH8YzIUjKec8mJAO+h6t38OBL+bJ9k/3Gzdcxc G8SBibJkqYS2zF3+0TSKsFWqVFGyQ0LcvbmGG3LXPEpvGCOS0SJRlIDZvEbkXK6i sDIeIjyWt9mlsNMmVCWDqJP5VREmbb5GDzJhP5dnxY0zz6MJR8AEOk/nvC10Hd2l c8oIwp/FZdn9czcyNhOvY29v/fgem9EnH7oqzfgjM19LCSji6qAylBe60yfVxRWs ZhaBmSIY3iIA6XYj6SeJ0Dllv9a+noZdo4lA+RcSQUtI9LXK7D0Ku0tdHna4go+v 0bqIqFYWEk2kIg2cf8tQ5sMSbjOwzCgxzCw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudejfedggeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhephfffheeljeffgeffueeghfekkedtfffgheejvdegjeettdduheeufffggfef jeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 15 Sep 2023 21:32:28 -0400 (EDT) Content-Language: en-US In-Reply-To: <83bke5mhvs.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:270570 Archived-At: On 14/09/2023 08:41, Eli Zaretskii wrote: >> Date: Wed, 13 Sep 2023 23:38:29 +0300 >> Cc: luangruo@yahoo.com, sbaugh@janestreet.com, yantar92@posteo.net, >> 64735@debbugs.gnu.org >> From: Dmitry Gutov >> >>> I think these questions are slightly premature. We should first have >>> the implementation of that filter, and then look for candidates that >>> could benefit from it. >> >> The implementation in that patch looks almost complete to me, unless you >> have any further comments. > > Fine, then please post a complete patch with all the bells and > whistles, and let's have it reviewed more widely. (I suggest a new > bug report, as this one is already prohibitively long to follow, > includes unrelated issues, and I fear some people will ignore patches > posted to it). I think there are a few subtleties we still need to > figure out. Sure, filed bug#66020. > If FILTER is the symbol ‘buffer’, it works like the default filter, > but makes some shortcuts to be faster: it doesn't adjust markers and > the process mark (something else?). > > Of course, the real text will depend on what the final patch will look > like: I'm not yet sure I understand which parts of > internal-default-process-filter you want to keep in this alternative > filter. (If you intend to keep all of them, it might be better to > replace internal-default-process-filter completely, perhaps first with > some variable exposed to Lisp which we could use to see if the new one > causes issues.) Very good. And thanks for pointing out the omissions, so I went with reusing parts of internal-default-process-filter. >>>> I'm not sure what negatives to test for, though. Raising the limit 10x >>>> is unlikely to lead to an OOM, but I guess some processes could grow >>>> higher latency?.. >>> >>> With a large buffer and small subprocess output we will ask the OS for >>> a large memory increment for no good reason. Then the following GC >>> will want to compact the gap, which means it will be slower. >> >> I wonder what scenario that might become apparent in. Launching many >> small processes at once? Can't think of a realistic test case. > > One process suffices. The effect might not be significant, but > slowdowns due to new features are generally considered regressions. We'd need some objective way to evaluate this. Otherwise we'd just stop at the prospect of slowing down some process somewhere by 9ns (never mind speeding others up).