From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#64735: 29.0.92; find invocations are ~15x slower because of ignores Date: Wed, 13 Sep 2023 22:32:03 +0300 Message-ID: <83il8dna30.fsf@gnu.org> References: <69a98e2a-5816-d36b-9d04-8609291333cd@gutov.dev> <87351cs8no.fsf@localhost> <35163e56-607d-9c5b-e3e8-5d5b548b3cb7@gutov.dev> <878rb3m43b.fsf@localhost> <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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5237"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, sbaugh@janestreet.com, yantar92@posteo.net, 64735@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Sep 13 21:33:14 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 1qgVbt-00013x-N8 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 13 Sep 2023 21:33:13 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qgVbf-0001fZ-5u; Wed, 13 Sep 2023 15:32:59 -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 1qgVbd-0001fJ-2Q for bug-gnu-emacs@gnu.org; Wed, 13 Sep 2023 15:32:57 -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 1qgVbc-0005ld-Pi for bug-gnu-emacs@gnu.org; Wed, 13 Sep 2023 15:32:56 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qgVbh-0005vm-Lr for bug-gnu-emacs@gnu.org; Wed, 13 Sep 2023 15:33:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 13 Sep 2023 19: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.169463355322760 (code B ref 64735); Wed, 13 Sep 2023 19:33:01 +0000 Original-Received: (at 64735) by debbugs.gnu.org; 13 Sep 2023 19:32:33 +0000 Original-Received: from localhost ([127.0.0.1]:36083 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qgVbE-0005v1-GQ for submit@debbugs.gnu.org; Wed, 13 Sep 2023 15:32:33 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47812) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qgVbA-0005um-0J for 64735@debbugs.gnu.org; Wed, 13 Sep 2023 15:32:31 -0400 Original-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 ) id 1qgVay-0005eK-2F; Wed, 13 Sep 2023 15:32:16 -0400 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=z8u8XtDibBmHLeS/Myf7pIOYA7LEmdU1n04fZ78sMR8=; b=E4I7XGiZc84y 4ylu6wx/ATF1g+TLl8O+bg8kRgfFwZL2Aiskf+rTCal/7rE1j9ydFKPpn5dv4oovuIZ3XFHfaxHWb un35wOyU8v8DleuGJE5/tXjo/5SSQ+F1LqVhuwV0eM8+FuxAXn7Am45rCoIt3rPBxzJSVlVdXx6Nv 57xGZjeMwjQjUho1668Qa1EwV/HF5rRn59CYkK3m0jf8f7YmYZjSmJWt8fqN+WCD1l5YS1IqMejI1 Bnxm4SHeD7UQ1CLVO2z2I+E7nO09VceUf2Jz7Wwc05kqoWfm1mnj2M1trkoBUD0CUGhkcPH4tw1mc inuUkJIGBTiy0AEVUSHpxg==; In-Reply-To: <26afa109-9ba3-78a3-0e68-7585ae8e3a19@gutov.dev> (message from Dmitry Gutov on Wed, 13 Sep 2023 20:27:09 +0300) 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:270356 Archived-At: > Date: Wed, 13 Sep 2023 20:27:09 +0300 > Cc: luangruo@yahoo.com, sbaugh@janestreet.com, yantar92@posteo.net, > 64735@debbugs.gnu.org > From: Dmitry Gutov > > >> Are you sure? IIUC the fact that is passes 'curbuf' as the last argument > >> to 'decode_coding_c_string' means that decoding happens inside the > >> buffer. This has been my explanation for the performance improvement anyway. > > > > Yes, you are right, sorry. > > So we're not going to try the gap-based approach? Okay. decode_coding_c_string does that internally. > >> The would be the safest alternative. OTOH, this way we'd pass up on the > >> opportunity to make all existing asynchronous processes without custom > >> filters, a little bit faster in one fell swoop. > > > > We could change the ones we care about, though. > > Which ones do we care about? I've found a bunch of 'make-process' calls > without :filter specified (flymake backends, ). Do we upgrade them all? > > The difference is likely not critical in most of them, but the change > would likely result in small reduction of GC pressure in the > corresponding Emacs sessions. > > We'll also need to version-guard the ones that are in ELPA. > > We don't touch the implementations of functions like start-file-process, > right? > > What about the callers of functions like > start-file-process-shell-command who want to take advantage of the > improvement? Are we okay with them all having to call > (set-process-filter proc 'buffer) on the returned process value? 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. My tendency is to change only callers which are in many cases expected to get a lot of stuff from a subprocess, so shell buffers are probably out. But we could discuss that later. > > We could also discuss changing > > the default value, but that would require measurements in as many > > cases as we can afford. > > If you have some particular scenarios in mind, and what to look out for, > I could test them out at least on one platform. Didn't think about that enough to have scenarios. > 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.