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 20:06:35 +0300 Message-ID: <838ro42b1g.fsf@gnu.org> References: <8335esjppt.fsf@gnu.org> <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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24442"; 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 19:12:38 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 1oJeOj-00067q-RF for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 04 Aug 2022 19:12:38 +0200 Original-Received: from localhost ([::1]:49644 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oJeOi-0003P1-Jc for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 04 Aug 2022 13:12:36 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46142) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJeJL-00032C-2E for bug-gnu-emacs@gnu.org; Thu, 04 Aug 2022 13:07:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36567) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oJeJK-0006UD-Q2 for bug-gnu-emacs@gnu.org; Thu, 04 Aug 2022 13:07:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oJeJK-00042z-Gd for bug-gnu-emacs@gnu.org; Thu, 04 Aug 2022 13:07: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 17:07: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.165963280915537 (code B ref 56682); Thu, 04 Aug 2022 17:07:02 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 4 Aug 2022 17:06:49 +0000 Original-Received: from localhost ([127.0.0.1]:54549 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oJeJ7-00042W-9T for submit@debbugs.gnu.org; Thu, 04 Aug 2022 13:06:49 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:33208) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oJeJ5-00042L-6N for 56682@debbugs.gnu.org; Thu, 04 Aug 2022 13:06:47 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:46114) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJeIx-0006Rf-5R; Thu, 04 Aug 2022 13:06:39 -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=L0twhICWyyg37xxZOafEcGGe0N2BdIJpPdRL3mMEmBw=; b=KWiUINhcFC2T wkGqPDtyiYK1MtMwj6+F5jxmWk4O0Op62DmpQ1aDFhvXniR1HjU2nVwkGPTX4DTZA2t/6oDUYNDlx mfy6XwqNQpNP7cvtoudO8Ij9uJXoaLaymWkDyvouzH0kidrrMLFl02EdgG8b7kuIRNPpE69cR9beM EInJk1Ea+yadswenCN2aXBmGiYej/Z1LMyoNbJ+AAu/sjppLi/ChU5fJ88nweQen7PRJcuyHUFJF9 vupQBjrJbxkzwXW+Y6o0LpiiLYy6h8WmTcldWXXTBDyVcicfASePn4egBCXMgdSF6s0BNdTTUuY/Q HRxoKNBhHCfIb/wW4cvO6Q==; Original-Received: from [87.69.77.57] (port=3709 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 1oJeIw-00060R-L0; Thu, 04 Aug 2022 13:06:38 -0400 In-Reply-To: <3d639ea126c6b0c6737b@heytings.org> (message from Gregory Heytings on Thu, 04 Aug 2022 16:25:28 +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:238774 Archived-At: > Date: Thu, 04 Aug 2022 16:25:28 +0000 > From: Gregory Heytings > cc: gerd.moellmann@gmail.com, 56682@debbugs.gnu.org, monnier@iro.umontreal.ca, > dgutov@yandex.ru > > > I'm on the branch, so I am _after_ the optimizations. I thought you > > said even after that the navigation is sluggish. > > Yes, that's what I said indeed. > > > I see somewhat slower response than in "normal" files, but my build is > > unoptimized, so where it takes 3 or 4 seconds, and optimized build > > should be almost instantaneous. And that looks good enough to me, since > > being a bit slower in such files is IMO fine. > > It's not really "almost instantaneous", moving point can take (depending > on factors I do not understand at the moment) something between 0.2 > seconds and 2 seconds. I saw slower response when point was at a parentesis or a brace -- due to show-paren-mode. Try disabling it and see if that affects performance. Another problem could be the BPA algorithm in bidi.c, but in my testing setting bidi-inhibit-bpa non-nil didn't affect performance in any tangible way, with this file. > > OK. Text that goes through character compositions is expected to be > > slower in redisplay, because character composition in Emacs works by > > calling into Lisp. > > So Arabic text goes through character compositions and Hebrew text > doesn't, is that correct? More accurately, Arabic text needs to call the shaping engine (HarfBuzz) for all the characters, whereas Hebrew does that only rarely (and not at all in locales.json). You can see from the composition rules in, respectively, lisp/language/misc-lang.el and lisp/language/hebrew.el that for Arabic, the entire range of Arabic characters is populated with composition rules in composition-function-table, whereas for Hebrew, only some relatively rare characters have non-nil rules. > > So I think we are good here, do you agree? > > 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.