From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers Date: Sun, 19 May 2024 22:38:45 -0400 Message-ID: References: <2c5c8afa-b57e-3156-d21c-5523cacb4d87@yandex.ru> <831qf1mgjl.fsf@gnu.org> <87cyyj9rpp.fsf@gnu.org> <65793.1694843596@localhost> <83ba27b7-4d28-4a3f-b803-4bc49f62986c@yandex.ru> <82993b86-0f34-4adb-a392-c74db5176d14@yandex.ru> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30708"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 53749@debbugs.gnu.org, Ikumi Keita , David Fussner , Arash Esbati , stefankangas@gmail.com, Tassilo Horn , Eli Zaretskii To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon May 20 04:40:23 2024 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 1s8swo-0007lJ-OV for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 20 May 2024 04:40:23 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s8swU-0005vM-2j; Sun, 19 May 2024 22:40:02 -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 1s8swQ-0005vD-Rv for bug-gnu-emacs@gnu.org; Sun, 19 May 2024 22:39:58 -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 1s8swP-0005Oc-Ph for bug-gnu-emacs@gnu.org; Sun, 19 May 2024 22:39:58 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1s8swT-0002Bl-Mc for bug-gnu-emacs@gnu.org; Sun, 19 May 2024 22:40:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 20 May 2024 02:40:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53749 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: pending patch Original-Received: via spool by 53749-submit@debbugs.gnu.org id=B53749.17161727448360 (code B ref 53749); Mon, 20 May 2024 02:40:01 +0000 Original-Received: (at 53749) by debbugs.gnu.org; 20 May 2024 02:39:04 +0000 Original-Received: from localhost ([127.0.0.1]:39357 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s8svX-0002Am-O9 for submit@debbugs.gnu.org; Sun, 19 May 2024 22:39:04 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:17804) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s8svS-0002AG-T0 for 53749@debbugs.gnu.org; Sun, 19 May 2024 22:39:02 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id A5174443B04; Sun, 19 May 2024 22:38:48 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1716172727; bh=cOM+3kFdKv9PtVZFMTDE7BkCYm59e5Vi5GmZe6tXuAo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=OR+Fyw7RSaXnOCHgirHHeSuSCed5S3tKhh1sN8iGPGVaLLD67Pdb5uKMKN+aCk6aD GpBWTLgnTH10PadN161ddqKqfONgnOiTYGfIzjwh3ajGPvS8mLY2naVsO4qIXHiLPo PaQeVFgtC5CsICE51Nz61Xp851SaVNFi3hUpq6TFl13RFaqD3guMreG4io/4HpoBQ0 rPeU7s2Z4dz1gSFHWb8Da+BBRep0ergE51d7QjUdcXkqAyZSpJP0w6XOQk/1/fFGGU Pqclw9hWl97L90KD6EoUMkniapEu9kgPE1fP125+QlNzDMg+UuFPEop7RMIc+XNEIF 4hV17jjnCEZdg== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 377B2443B0C; Sun, 19 May 2024 22:38:47 -0400 (EDT) Original-Received: from pastel (unknown [45.72.201.215]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id E222A1204F5; Sun, 19 May 2024 22:38:46 -0400 (EDT) In-Reply-To: (Dmitry Gutov's message of "Mon, 20 May 2024 03:21:33 +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:285460 Archived-At: >> Hmm... not sure it's worth the trouble, then. >> Also, it might be worth trying to see where those 4-10% are spent: this >> is done in a temp buffer where there should presumably be very little >> need for before/after-change-functions, so maybe we can get rid of the >> specific offenders rather than inhibit all modification hooks. > Given the relatively low percentages, it might be difficult to glance from > a profiler report. I was assuming the time was mostly spent in > syntax-ppss-flush-cache, but the function is pretty simple. Rather than a profiler report, maybe a better approach would be to remove things from the non-inhibited-modification-hooks paths and see how/if they change the performance. E.g. replace the `inhibit-modification-hooks` binding by one that binds `before/after-change-functions` to nil. >> I wonder what we do during those 20% of the time if the buffer is left >> in fundamental-mode. > Good question. It's probably the better case to investigate since it might be easier to see the effects. >>>> Also, what about the other two bindings of `inhibit-modification-hooks`? >>> The other two are used while the contents of the Xref buffer are printed (or >>> re-printed), so there's none of the syntax-ppss complications there. The >>> performance difference is 8.5% in my last measurement. >> Is this 8.5% of a function that's fast anyway of 8.5% of a function >> which takes a fair bit of time? > When there are a lot of matches, it can take some time. Note that 100% in > this case is the whole list-files-do-search-print-results pipeline, not just > the printing phase. So printing is sped up by more than 8% (my last test > says it's by 27%). I guess during printing if it's done in many small steps we may indeed run modification hooks many times, so that could explain the higher percentage. It still seems hard to justify 27% since those modification hooks should usually do nothing, AFAICT. Maybe there's something silly going on. Stefan