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 14:38:43 +0300 Message-ID: <83ledanvzw.fsf@gnu.org> References: <83bd4246-ac41-90ec-1df3-02d0bd59ca44@gutov.dev> <834jlttv1p.fsf@gnu.org> <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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10394"; 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 13:40:22 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 1qgOEG-0002S6-93 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 13 Sep 2023 13:40:20 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qgODu-0008H5-Gx; Wed, 13 Sep 2023 07:39:58 -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 1qgODt-0008Gn-BZ for bug-gnu-emacs@gnu.org; Wed, 13 Sep 2023 07:39: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 1qgODt-0008Nf-3E for bug-gnu-emacs@gnu.org; Wed, 13 Sep 2023 07:39:57 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qgODy-0005JT-2S for bug-gnu-emacs@gnu.org; Wed, 13 Sep 2023 07:40: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 11:40: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.169460515120356 (code B ref 64735); Wed, 13 Sep 2023 11:40:02 +0000 Original-Received: (at 64735) by debbugs.gnu.org; 13 Sep 2023 11:39:11 +0000 Original-Received: from localhost ([127.0.0.1]:60954 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qgOD8-0005IF-BL for submit@debbugs.gnu.org; Wed, 13 Sep 2023 07:39:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43088) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qgOD6-0005I2-0v for 64735@debbugs.gnu.org; Wed, 13 Sep 2023 07:39:09 -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 1qgOCu-0008Af-KX; Wed, 13 Sep 2023 07:38:56 -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=OOjaOQ+avF9SXZYieipNqFMRzI2rBjiRDZy4dy6P2eg=; b=ojck29XUVHmF e+sw+h+nysdFLqIXKpWlq7eMxDOLIQk7PvdeZdmO7dmGE3w4mR+8zLvnAQSJpCDe5JQIiZFEyN9pV l426RwV/Salel2pYNG5XvhXjUQZr4rxqpTbyx4fJ14ZjEV5yTdEtb3Z+XmvaXVyzoW/2lYr5JGOf0 qPDUDoeKtt50GMNzrHBCpm6O1VLGdHcAmLzIoQMdx6TNfYJkGk0QJUBRs76+2yqS4Yyka+sLo//ET HUpupbW29uDs+U1LNRe4L1M/qlWQ5/xsE1sZZQkxfhWDuXg72k73z5DLkFWz1AQ99mao256+FiJCx b7Q6LUwr8/8erxNhinv7Dw==; In-Reply-To: <5c493f86-0af5-256f-41a7-7d886ab4c5e4@gutov.dev> (message from Dmitry Gutov on Tue, 12 Sep 2023 23: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:270260 Archived-At: > Date: Tue, 12 Sep 2023 23:27:49 +0300 > Cc: luangruo@yahoo.com, sbaugh@janestreet.com, yantar92@posteo.net, > 64735@debbugs.gnu.org > From: Dmitry Gutov > > > That's why I said "or writing a new filter function". > > read_and_dispose_of_process_output will have to call this new filter > > differently, passing it the raw text read from the subprocess, where > > read_and_dispose_of_process_output current first decodes the text and > > produces a Lisp string from it. Then the filter would need to do > > something similar to what insert-file-contents does: insert the raw > > input into the gap, then call decode_coding_gap to decode that > > in-place. > > 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. Did you look at what insert-file-contents does? If not I suggest to have a look, starting from this comment: /* Here, we don't do code conversion in the loop. It is done by decode_coding_gap after all data are read into the buffer. */ and ending here: if (CODING_MAY_REQUIRE_DECODING (&coding) && (inserted > 0 || CODING_REQUIRE_FLUSHING (&coding))) { /* Now we have all the new bytes at the beginning of the gap, but `decode_coding_gap` can't have them at the beginning of the gap, so we need to move them. */ memmove (GAP_END_ADDR - inserted, GPT_ADDR, inserted); decode_coding_gap (&coding, inserted); inserted = coding.produced_char; coding_system = CODING_ID_NAME (coding.id); } else if (inserted > 0) { /* Make the text read part of the buffer. */ eassert (NILP (BVAR (current_buffer, enable_multibyte_characters))); insert_from_gap_1 (inserted, inserted, false); invalidate_buffer_caches (current_buffer, PT, PT + inserted); adjust_after_insert (PT, PT_BYTE, PT + inserted, PT_BYTE + inserted, inserted); } > The result there, though, is that a "filter" (in the sense that > make-process uses that term) is not used at all. 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. > > And if we want to use it in production, we should > > probably work on adding that special default filter which inserts and > > decodes directly into the buffer, because that will probably lower the > > GC pressure and thus has hope of being faster. Or even replace the > > default filter implementation with that new one. > > But a filter must be a Lisp function, which can't help but accept only > Lisp strings (not C string) as argument. Isn't that right? 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. Any Lisp callback could then access the process output as the text of that buffer, no Lisp strings needed. I thought this was a worthy goal; apologies if I misunderstood.