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#74243: [PATCH] Speed up vc-hg-state by treating ignored files as unregistered Date: Wed, 27 Nov 2024 02:18:39 +0200 Message-ID: <48e27733-61a8-49d2-94b2-109c98b3dd7f@gutov.dev> References: <87mshy7jtp.fsf@melete.silentflame.com> <87r06ytosi.fsf@melete.silentflame.com> <802729a0-6937-48a7-9ce5-bd81e8548877@gutov.dev> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16656"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: 74243@debbugs.gnu.org, Sean Whitton To: Spencer Baugh Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Nov 27 01:19:25 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 1tG5m8-0004BR-JR for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 27 Nov 2024 01:19:25 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tG5lp-0008IQ-FI; Tue, 26 Nov 2024 19:19:05 -0500 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 1tG5lm-0008I8-Ty for bug-gnu-emacs@gnu.org; Tue, 26 Nov 2024 19:19:03 -0500 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 1tG5lm-0007Hq-L1 for bug-gnu-emacs@gnu.org; Tue, 26 Nov 2024 19:19:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=In-Reply-To:From:References:MIME-Version:Date:To:Subject; bh=CLfaqt510JPAczD20Em3M9YZW2BzlCXsKzoekwy9G+4=; b=NxRmbVyXVlKsghdv0GsDneHRRlX7GGFCrvbppJRfzOAggf3y4CNTiPVmuocnFU37y7gv2r/18/xdnJfbGo+PotxDn0Yf+lj1g8uiuOV9uvxNUc/KkDyh5tT6y6rGtHooGC1zued++LOaJ4jGyzfIbFPoo2CMHboI44MQDE9vCgewXbrpABJf3x7EORoyOYalf8sG5I92YoEvj1hZzaxFrSc3bhyAVK+M4glSnDQoDepT9RSs6bAjnj6eUtIWln//GAdVYLdrCqqvcZHmCXWmWUIN6nSed3NDSc+rmCLRQp/Z6ctW4zjQrl77KjyG72OzSVcRJyAtjP4lzNrbtOjPGA==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tG5lm-0001cD-Gj for bug-gnu-emacs@gnu.org; Tue, 26 Nov 2024 19:19:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 27 Nov 2024 00:19:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74243 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 74243-submit@debbugs.gnu.org id=B74243.17326667316186 (code B ref 74243); Wed, 27 Nov 2024 00:19:02 +0000 Original-Received: (at 74243) by debbugs.gnu.org; 27 Nov 2024 00:18:51 +0000 Original-Received: from localhost ([127.0.0.1]:55491 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tG5lb-0001bi-Cf for submit@debbugs.gnu.org; Tue, 26 Nov 2024 19:18:51 -0500 Original-Received: from fhigh-b4-smtp.messagingengine.com ([202.12.124.155]:55925) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tG5lZ-0001bQ-DL for 74243@debbugs.gnu.org; Tue, 26 Nov 2024 19:18:50 -0500 Original-Received: from phl-compute-11.internal (phl-compute-11.phl.internal [10.202.2.51]) by mailfhigh.stl.internal (Postfix) with ESMTP id CEAEE254011B; Tue, 26 Nov 2024 19:18:43 -0500 (EST) Original-Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-11.internal (MEProxy); Tue, 26 Nov 2024 19:18:43 -0500 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:subject:subject:to:to; s=fm2; t=1732666723; x=1732753123; bh=CLfaqt510JPAczD20Em3M9YZW2BzlCXsKzoekwy9G+4=; b= EU4C8kHofJmOuFO1beDBAMHW5cqv9lJGGibvmks4dz+gqVhks2Qsgx0WMd8qQcAM Ky+nJ1pJ+zHBIEN/gv9/s//A1sBqZLZ/lbAl+YNp1r1RZaau6Cu+G72b6mv97uI5 nsw/YU3aAiFfk/6cfwDc5cMJppzc2jUelYylTjqpp806xUAzVr6l9fmPzYGm5ORq 3lnOKn3/o+PQVst6+4iZtLhmHSy1zJyPZ5MBXY0KCGar31vxLZfFIm+po0ckp6zs Sf/r4nGbBeXnr16fZl/A69kZaQoFHZ4gkGGvu9tyUx5pFdUVlGh0hspMz+ENfrVW VXYBSN3AhVV9PsEZhEOF3w== 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:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1732666723; x= 1732753123; bh=CLfaqt510JPAczD20Em3M9YZW2BzlCXsKzoekwy9G+4=; b=G seY43A002WPhJOcENvOkmPRe1a28USVqyY1Q+YbN2koOLN8PAP0hXmAgBHRO/5xL bB5cAJpA385n45SoiSFe96XPZBSA5MBQE/Z3bzXSzI+uoEr7H4bpvflsi2+ctbqU 0egb4ean9aKlwe9Gp9leTs9md2ga2weAv7RjVaHqP2yZxvfbyvNkd+eBwUwWcR5n Q35zcv/USZL72HoMknbTgjdlwu48HvwrxJFWseK+FQKDXnx/85R3GuufPXg6bn3Z SGhV8Hx0nUqc/ex3cQLbHe3JbIWY/vr7g4JVOUjNreGIEsZ7Lhzk6lc2DWwqcBhg R14eYQQ7seQn5tLMLpvHA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrgeekgddvtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdpuffr tefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnth hsucdlqddutddtmdenucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeen ucfhrhhomhepffhmihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvg hvqeenucggtffrrghtthgvrhhnpeetudeljeegheetgfehgeejkeeuhedvveeikeeufedt vddtveefhfdvveegudejheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpegumhhithhrhiesghhuthhovhdruggvvhdpnhgspghrtghpthhtohep fedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepshgsrghughhhsehjrghnvghsth hrvggvthdrtghomhdprhgtphhtthhopehsphifhhhithhtohhnsehsphifhhhithhtohhn rdhnrghmvgdprhgtphhtthhopeejgedvgeefseguvggssghughhsrdhgnhhurdhorhhg X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 26 Nov 2024 19:18:41 -0500 (EST) Content-Language: en-US In-Reply-To: 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:296008 Archived-At: On 27/11/2024 01:32, Spencer Baugh wrote: >> A user option seems like an easier choice. >> >> Solutions that clear cache under some conditions or other tend to be >> more complex, and slow down at least some combined scenarios (e.g. one >> of my use cases is saving the buffer and having diff-hl-mode use its >> vc state from after-save-hook). > > These are all reasonable concerns. > > Since posting my original patch, though, I've heard from Hg developers > that they plan to eventually implement per-directory ignore files, like > in Git. That would remove the original performance problem, so maybe > this is not so important. That's good to hear. > That being said, it's still sad that the vc hooks in find-file-hook and > after-save-hook can hurt performance so much. Understandable, that's what drove me to implement that older change in Git back then. > It seems to me that the ideal outcome would be to support asynchronicity > in those hooks. That would benefit all vc backends... though this is > perhaps quite difficult. The most complex part could be retaining a compatible/synchronous API. > Maybe asynchronously populating the saved vc-state property would work? > With some clever usage of nil return values as Sean describes... Maybe Sean's idea is better, but to spitball different options: - FWIW since not too long ago we've treated a similar issue in diff-hl by using a thread - which calls the same code inside (meaning the current synchronous implementation), but it happens in the background, so the input is unfrozen and the visual update is asynchronous. But keeping in mind that threads' error handling is not great, so it seems not optimal to keep a lot of implementation code inside a thread. Also, threads are reportedly not good with remote calls yet. - The mode-line update isn't going to wait asynchronously, though, but perhaps an update could be scheduled. If state updates are not synchronous, I suppose this would also need some debouncing/queueing mechanism for the callers as well. That is the route of migrating to a different calling convention, though. - Finally, if the main scenario that we are concerned is the use in vc-dir, we could try switching only its updates to another backend call. E.g. vc-dir-resynch-file would switch to the (possibly) more precise - though slower - dir-status-files, just like the code that first populates that buffer. vc-state could then afford shortcuts more safely.