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 18:07:48 +0300 Message-ID: <83r0n2m7qz.fsf@gnu.org> References: <937c3b8e-7742-91b7-c2cf-4cadd0782f0c@gutov.dev> <83a5vlsanw.fsf@gnu.org> <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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11801"; 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 17:09:16 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 1qgRUS-0002pG-Er for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 13 Sep 2023 17:09:16 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qgRUB-0004ZI-83; Wed, 13 Sep 2023 11:08: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 1qgRU9-0004Yi-Dy for bug-gnu-emacs@gnu.org; Wed, 13 Sep 2023 11:08: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 1qgRU9-00063G-5s for bug-gnu-emacs@gnu.org; Wed, 13 Sep 2023 11:08:57 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qgRUE-0005I9-3X for bug-gnu-emacs@gnu.org; Wed, 13 Sep 2023 11:09:02 -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 15:09:02 +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.169461769520288 (code B ref 64735); Wed, 13 Sep 2023 15:09:02 +0000 Original-Received: (at 64735) by debbugs.gnu.org; 13 Sep 2023 15:08:15 +0000 Original-Received: from localhost ([127.0.0.1]:35647 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qgRTT-0005H9-A0 for submit@debbugs.gnu.org; Wed, 13 Sep 2023 11:08:15 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56124) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qgRTQ-0005Gq-MI for 64735@debbugs.gnu.org; Wed, 13 Sep 2023 11:08:14 -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 1qgRTF-0005tL-8O; Wed, 13 Sep 2023 11:08:01 -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=P9+tH0UISD2MLZiMZ3tAEzZoaPa7jA2EjoJzp7FNr/Y=; b=WYWJL3LF6GnT VCDXFBve8y/JJN1UL5CFoIT9qElM22BosGeEbsMlIKyCUdGmebjk1MLnXITWSC8avRT+PUJzp5Mak qwzivg3YN0esahY7e6DZ5ubpRGQt4qB4mv0zmC98DQ/1+X0hd7zR99Q/qbV69qtF/R5wNUjZCq+9T CM6+ndYLJXFrhJo0K50aZdFsDGH+ei1xrE1gmRfcyNzN6f2ALM4kRgeSZxEcxQhFT9fwXVuHpd8d3 od+Nt3Xwao9AgRP5XNVaeLX/+RUlrJIdfaEdP5a0jEw/JbRslaysyJ2qk2oIFGtWDcUjqqodMskYI bN3+T2oWoftS1M7P7IhlZw==; In-Reply-To: (message from Dmitry Gutov on Wed, 13 Sep 2023 17:27:49 +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:270312 Archived-At: > Date: Wed, 13 Sep 2023 17:27:49 +0300 > Cc: luangruo@yahoo.com, sbaugh@janestreet.com, yantar92@posteo.net, > 64735@debbugs.gnu.org > From: Dmitry Gutov > > >> Does the patch from my last patch-bearing email look similar enough to > >> what you're describing? > >> > >> The one called read_and_insert_process_output.diff > > > > No, not entirely: it still produces a Lisp string when decoding is > > needed, and then inserts that string into the buffer. > > 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. > > Sure, but in this case we don't need any filtering. It's basically > > the same idea as internal-default-process-filter: we just need to > > insert the process output into a buffer, and optionally decode it. > > Pretty much. But that raises the question of what to do with the > existing function internal-default-process-filter. Nothing. It will remain as the default filter. > Looking around, it doesn't seem to be used with advice (a good thing: > the proposed change would break that), but it is called directly in some > packages like magit-blame, org-assistant, with-editor, wisi, sweeprolog, > etc. I suppose we'd just keep it around unchanged. Yes. > > We can provide a special filter identified by a symbol. Such a filter > > will not be Lisp-callable, it will exist for the cases where we need > > to insert the output into the process buffer. > > 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. > Should we also discuss increasing the default of > read-process-output-max? Even increasing it 10x (not necessarily 100x) > creates a noticeable difference, especially combined with the proposed > change. That should be limited to specific cases where we expect to see a lot of stuff coming from the subprocess. We could also discuss changing the default value, but that would require measurements in as many cases as we can afford.