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: Wed, 10 Aug 2022 20:19:49 +0300 Message-ID: <838rnwqami.fsf@gnu.org> References: <83mtcizov2.fsf@gnu.org> <83h72qzheq.fsf@gnu.org> <25717d84-3411-a93a-3620-e04fe0571aff@yandex.ru> <83edxuzemr.fsf@gnu.org> <83a68hzz0a.fsf@gnu.org> <6ae35c93062c589b2e02@heytings.org> <7b7fbad7-55ac-49b8-840f-7f89a7e8771a@yandex.ru> <6ae35c93064b3588974c@heytings.org> <6ae35c9306c515f420d8@heytings.org> <87k07gwkjq.fsf@gmx.net> <87fsi4wiel.fsf@gmx.net> <837d3gs4p0.fsf@gnu.org> <83tu6kqnf1.fsf@gnu.org> <83fsi4qdxp.fsf@gnu.org> <2aa80c8f-5fb8-1892-72cd-60f050261104@yandex.ru> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25653"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 56682@debbugs.gnu.org, gregory@heytings.org, stephen.berman@gmx.net, monnier@iro.umontreal.ca To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Aug 10 19:26:19 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 1oLpTH-0006Xs-Ep for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 10 Aug 2022 19:26:19 +0200 Original-Received: from localhost ([::1]:49544 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oLpTG-0003xp-Db for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 10 Aug 2022 13:26:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54798) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oLpOA-0000Aa-P1 for bug-gnu-emacs@gnu.org; Wed, 10 Aug 2022 13:21:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:60893) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oLpOA-0002om-Gt for bug-gnu-emacs@gnu.org; Wed, 10 Aug 2022 13:21:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oLpOA-0001up-Ch for bug-gnu-emacs@gnu.org; Wed, 10 Aug 2022 13:21: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: Wed, 10 Aug 2022 17:21: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.16601520107262 (code B ref 56682); Wed, 10 Aug 2022 17:21:02 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 10 Aug 2022 17:20:10 +0000 Original-Received: from localhost ([127.0.0.1]:50642 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLpNJ-0001t4-Ij for submit@debbugs.gnu.org; Wed, 10 Aug 2022 13:20:09 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:41632) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLpNF-0001sS-Pz for 56682@debbugs.gnu.org; Wed, 10 Aug 2022 13:20:08 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:37756) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oLpN9-0002NE-Ux; Wed, 10 Aug 2022 13:20:00 -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=rEVPVA4ZMdP7uox2mdAlg5WFMVQvMGNZ8Bka4gNvmFA=; b=bYI1Wb8ey2Jw t4wp1KUKHO1tkI4pBxIWyP6fXLjNhNpVd+Rz1EuGPgpF1vByCYvePJJG2goRINoS1fJkIb71ZxVcD C2utn5vfu5LXj8OpOaUC1hdi1EPOmJC36AVx78g7Z/SAZgxbvQUCkVPOBfkAv/Vz089Fgjidtj711 W7KKTBXZuwzxXBNlSafUIw6L9VJZzUT39qJS8zCeS5x5gf4mFn6jwmZVtYTM5j0M3Za13jmht+7X3 guQkYSlb7FvCYiBOVdj+4PSJkrMHjg2sEAYuevGYMkN8NGD48ifEJJVCPCU+4Z9NKZ87sFVm0z6Xw 9tQI2aKWV/kzuOOeuxU6uA==; Original-Received: from [87.69.77.57] (port=4895 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 1oLpN9-0003AE-Cz; Wed, 10 Aug 2022 13:19:59 -0400 In-Reply-To: <2aa80c8f-5fb8-1892-72cd-60f050261104@yandex.ru> (message from Dmitry Gutov on Wed, 10 Aug 2022 20:02:20 +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" Xref: news.gmane.io gmane.emacs.bugs:239312 Archived-At: > Date: Wed, 10 Aug 2022 20:02:20 +0300 > Cc: 56682@debbugs.gnu.org, gregory@heytings.org, stephen.berman@gmx.net, > monnier@iro.umontreal.ca > From: Dmitry Gutov > > It's much worse. In the aforementioned dictionary.json, with > fully-featured font-lock (narrowing disabled in handle_fontified_props) > the buffer is perfectly responsive to edit as long as I (setq > bidi-inhibit-bpa nil). Even with show-paren-mode enabled. > > Without that, however, simple navigation commands take a significant > amount of time. These measurements are with show-paren-mode off: > > Near BOB: > > (benchmark 1 '(next-line 1)) => > Elapsed time: 0.246551s > Elapsed time: 0.247237s > Elapsed time: 0.247392s > > Near EOB: > > (benchmark 1 '(next-line 1)) => > Elapsed time: 0.059583s > Elapsed time: 0.040372s > Elapsed time: 0.059508s That's what I meant: it isn't a catastrophe. 1/4th of a second for C-n is barely perceptible. "Catastrophe" in my book is when it takes more than a couple of seconds, like 10 sec or more. > > not > > like we've seen with the files we used for the long-lines speedups. > > And if someone does think it's a catastrophe, they can always disable > > the BPA, perhaps even globally, > > That reminds me of "the user can always disable font-lock" and your > dismissal of Alan's advice to change font-lock-maximum-decoration to 2, > saying that we should have good editing performance OOTB. No, because font-lock is much more important than the effect of the BPA. (Do you even understand what the BPA does, and did you ever see it in action? Without that, this part of the discussion is just waste of time.) > > if they know they will never need to > > look closely at bidirectional text: the effects are hardly visible > > unless you actually read the text. > > We could add (setq bidi-inhibit-bpa nil) to prog-mode, I suppose. Not to prog-mode, that I won't agree. But maybe for JSON files, if we think they are unlikely to suffer. > It already has a bidi-paragraph-direction setting anyway. That's not even similar. That's just saving Emacs to figure that out itself, wasting CPU cycles on what is known in advance. Because a PL buffer _always_ has its paragraphs left-to-right. > > This is impossible without a complete redesign of how the bidi display > > works: it saves no information in the buffer object, none whatsoever. > > The information is recomputed every time the display code is called, > > and only for the portion of the buffer that needs to be traversed or > > displayed; then it is discarded. There are no caches of any kind that > > keep the information after redisplay has done its job. > > Perhaps a cache similar to syntax-ppss one could do the job? Not sure > what would be the trafeoffs, though. Like, how that would change the > performance in the simple case. There are no caches for a good reason: the Unicode Bidirectional Algorithm that we implement results in very far-reaching non-local effects of small changes. Even inserting or deleting a single character can dramatically change how the buffer looks on display very far from the locus of the change. Figuring out which changes invalidate which caches is extremely non-trivial, and in many cases requires the same amount of work as would take to just recompute everything from scratch.