From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Achim Gratz Newsgroups: gmane.emacs.bugs Subject: bug#45320: 27.1; diff-refine performance regression Date: Mon, 13 Jun 2022 17:11:00 +0200 Organization: Linux Private Site Message-ID: <87o7ywvbsr.fsf@Rainer.invalid> References: <87a6ua5i4b.fsf@Rainer.invalid> <87h74wk898.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6952"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) To: 45320@debbugs.gnu.org Cancel-Lock: sha1:iXXDshjGcTIzFzY5jTE18h2eO+U= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jun 13 17:12:11 2022 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 1o0ljf-0001ci-8n for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 13 Jun 2022 17:12:11 +0200 Original-Received: from localhost ([::1]:60622 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o0lje-0003A2-As for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 13 Jun 2022 11:12:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57886) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o0ljW-00039t-53 for bug-gnu-emacs@gnu.org; Mon, 13 Jun 2022 11:12:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:38001) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o0ljV-0005QG-Sd for bug-gnu-emacs@gnu.org; Mon, 13 Jun 2022 11:12:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1o0ljV-0001si-OC for bug-gnu-emacs@gnu.org; Mon, 13 Jun 2022 11:12:01 -0400 X-Loop: help-debbugs@gnu.org In-Reply-To: <87a6ua5i4b.fsf@Rainer.invalid> Resent-From: Achim Gratz Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Jun 2022 15:12:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45320 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.16551330877185 (code B ref -1); Mon, 13 Jun 2022 15:12:01 +0000 Original-Received: (at submit) by debbugs.gnu.org; 13 Jun 2022 15:11:27 +0000 Original-Received: from localhost ([127.0.0.1]:60131 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o0lix-0001ro-Cn for submit@debbugs.gnu.org; Mon, 13 Jun 2022 11:11:27 -0400 Original-Received: from lists.gnu.org ([209.51.188.17]:39878) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o0liv-0001re-1p for submit@debbugs.gnu.org; Mon, 13 Jun 2022 11:11:25 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57718) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o0liu-00037f-T7 for bug-gnu-emacs@gnu.org; Mon, 13 Jun 2022 11:11:24 -0400 Original-Received: from ciao.gmane.io ([116.202.254.214]:43872) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o0lig-0005Lu-OA for bug-gnu-emacs@gnu.org; Mon, 13 Jun 2022 11:11:24 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1o0lie-0000Ln-2g for bug-gnu-emacs@gnu.org; Mon, 13 Jun 2022 17:11:08 +0200 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=geb-bug-gnu-emacs@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action 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" Xref: news.gmane.io gmane.emacs.bugs:234418 Archived-At: Lars Ingebrigtsen writes: > This isn't the common use case for showing diffs, so it sounds like you > should just alter the 'diff-refine' user option as described above. The problem is caused by a change in defaults and whether or not the use case seems common to you is besides the point. The default used to be no refinement and the change in default was done on the assumption that the performance hit would generally not be bothersome. As long as (GNU) grep does have this clearly superlinear complexity characteristic that simply isn't true (just for entertainment I've let Emacs hang while grep finishes the refinement several times and it is not uncommon that I see grep taking several minutes. I think the longest I've kept it running was way over one hour. >> Auto-refinement of diff hunks should >> >> 1. be stopped >> >> a) after a customizable time threshold (personally I'd be OK with >> something like 1s, but other folks may have less patience), >> >> b) when the user tries to move point (even small delays are annoying >> when you really just want to scroll through the file), >> >> c) when C-g or the corresponding signal is issued. > > The problem with of these is that font-locking is done from > redisplay, and if you `C-g' something from those functions, it'll just > try to restart the fontification. But... I guess we could slap > something around `diff--font-lock-refined' to change the value > (buffer-locally) of diff-refine if the user hits `C-g' while it's > running? My go-to solution is to send USR2 to the emacs process, but that's really not something I should ever need to do with an Emacs in standard configuration. >> 2. not be attempted at all >> >> a) when the hunk size exceeds a customizable threshold, > > That should be possible... The hunk size only factors into this due to the superlinear complexity in the refinement. It might be tricky to figure out a size that works across all inputs since the structure of the hunk is also important. >> b) when the diff in question has run into one of the performance >> thresholds multiple times already. > > I'm not sure that's practical. > > Anybody have any other ideas here? Ideally all such external processes should run asynchronously (as a "future") with a timeout. If there is a timeout event, the user presses C-g or point is moved to a different hunk before the result gets delivered the process simply gets canceled, otherwise there is another round of redisplay that is using the result. I guess that caching previous results would be quite useful at least in this particular case, so the details of the implementation could become quite involved. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada