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#56682: Fix the long lines font locking related slowdowns Date: Thu, 04 Aug 2022 21:52:48 +0300 Message-ID: <83wnbn264f.fsf@gnu.org> References: <837d43j198.fsf@gnu.org> <83y1wjhkkh.fsf@gnu.org> <83wnc3hkdg.fsf@gnu.org> <49df74e5-e16a-a532-98d1-66c6ff1eb6c6@yandex.ru> <83pmhuft5a.fsf@gnu.org> <05388e8d8836c2e7ef3e@heytings.org> <136c4fe0fcb9ce5181cb@heytings.org> <3d639ea12689d767ba2a@heytings.org> <838ro44fc8.fsf@gnu.org> <3d639ea126d759bddfea@heytings.org> <83y1w42vp4.fsf@gnu.org> <3d639ea12618e6a503af@heytings.org> <83wnbo2uw3.fsf@gnu.org> <3d639ea126e3a4d880b8@heytings.org> <83k07o2izh.fsf@gnu.org> <3d639ea1265c40a07f40@heytings.org> <83h72s2e3o.fsf@gnu.org> <3d639ea126c6b0c6737b@heytings.org> <838ro42b1g.fsf@gnu.org> <3d639ea126db3913202e@heytings.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9699"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gerd.moellmann@gmail.com, 56682@debbugs.gnu.org, monnier@iro.umontreal.ca, dgutov@yandex.ru To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Aug 04 20:54:18 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 1oJfz6-0002Lr-U2 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 04 Aug 2022 20:54:17 +0200 Original-Received: from localhost ([::1]:34988 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oJfz5-0006nZ-U3 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 04 Aug 2022 14:54:15 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38758) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJfyt-0006h5-BH for bug-gnu-emacs@gnu.org; Thu, 04 Aug 2022 14:54:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36971) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oJfys-0006dw-GZ for bug-gnu-emacs@gnu.org; Thu, 04 Aug 2022 14:54:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oJfys-00034F-9X for bug-gnu-emacs@gnu.org; Thu, 04 Aug 2022 14:54: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: Thu, 04 Aug 2022 18:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56682 X-GNU-PR-Package: emacs Original-Received: via spool by 56682-submit@debbugs.gnu.org id=B56682.165963919511732 (code B ref 56682); Thu, 04 Aug 2022 18:54:02 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 4 Aug 2022 18:53:15 +0000 Original-Received: from localhost ([127.0.0.1]:54953 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oJfy5-000339-BN for submit@debbugs.gnu.org; Thu, 04 Aug 2022 14:53:15 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:53938) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oJfxq-00032J-P7 for 56682@debbugs.gnu.org; Thu, 04 Aug 2022 14:53:11 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:48002) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJfxk-0006ZV-NM; Thu, 04 Aug 2022 14:52:52 -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=sHC2n+vukNLsAInYmoq2sUDVg3dp42tLpCKU08F6aCw=; b=jxUvAwovoc2c y0YLY6twEE0D0IohJ8B/9cyFWUjJ6k6wA67H6XzocX+kyL+bAbrwnNCJ2btU2Wl67XYPUkZwHAcvH 03+onaDBDQIighk1R801f/O3rY07NN3owkmomcXlmxB1zBVwn080IqEheK5m/rbK3wpmr8PgF6GlK GUagkXHQmQ/cRiQxhMXxFNDYCZ9XS52F4RW2+aNoi6fDuVsA8qQFgXIhGTs6An4IqmNyQWY8UMs/v 32eT7JeRvCTsPYHwZNLVIh/+juKtxMTVYCQaEqbS6JoMEV0Rjp7kxZwXnOAb+fi/IMv8vPthaUJs7 Yhf16/v3gMD92DHV2ixX5w==; Original-Received: from [87.69.77.57] (port=2443 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJfxk-0000Fi-6U; Thu, 04 Aug 2022 14:52:52 -0400 In-Reply-To: <3d639ea126db3913202e@heytings.org> (message from Gregory Heytings on Thu, 04 Aug 2022 18:16:02 +0000) 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:238789 Archived-At: > Date: Thu, 04 Aug 2022 18:16:02 +0000 > From: Gregory Heytings > cc: gerd.moellmann@gmail.com, 56682@debbugs.gnu.org, monnier@iro.umontreal.ca, > dgutov@yandex.ru > > >> Hmmm... I still think it would be possible to do better. With the > >> above recipe (M-g g 70000 RET C-n), composition_compute_stop_pos is > >> called 627663 times and uses about 2 seconds of CPU time. What > >> surprises me (and makes me believe it's perhaps possible to do better) > >> is that it is called repeatedly with the same arguments. For example, > >> when doing C-n it is called 26 times with charpos = 69980. > > > > I'll see where these come from and whether some of them could be > > avoided. > > > > Are you capable of running under perf and producing the profile of these > > commands? Because I wonder whether we correctly identify the main > > bottlenecks in these scenarios. > > > > I can't speak in general, but in this particular scenario, the bottleneck > is clearly composition_compute_stop_pos. I looked into this, and I don't see how this could be avoided, unfortunately, not without disabling auto-composition-mode (which I'm told produces display of Arabic that makes readers of that script turn away in disgust). Disabling auto-composition-mode makes navigation there about twice faster, as fast as in the other parts of the file. The problem here is that bidi iteration through buffer text is non-linear (it follows the visual order, not the order of buffer positions), so the iterator frequently finds itself out of sync with the next known "stop position", and needs to resync, to be able to find which faces, overlays, and invisible and display properties are in effect. That's what handle_stop_backwards does, and that involves going back and rescanning text. With Arabic, this is exacerbated by the fact that every Arabic character is "composable" (in the sense of the CHAR_COMPOSED_P macro), and triggers a call to composition_compute_stop_pos to find the next (or previous) one. And on top of that, C-n calls pos-visible-in-window-p two or 3 times, posn-at-point 2 times, and then vertical-motion. Each one of these needs to scan text around point starting from the beginning of the previous visible line. The narrowing limits that to some reasonable distance, but it is still several thousand characters back. So if composition_compute_stop_pos is the bottleneck, perhaps some simple caching could help? But note that when this function is called twice with the same character position, it is called to search in different directions -- once forward and another time back. So even such low-hanging fruit is not simple to reap, as these two calls will return two different results. For now, I don't see how to speed this up, without producing woefully incorrect display. I will keep thinking, but I'm not too worried about this case, since the current performance is tolerable enough, even if somewhat sluggish. > You didn't tell me whether it's okay to merge the branch with the latest > changes? I think you can merge.