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#56682: Fix the long lines font locking related slowdowns Date: Sat, 13 Aug 2022 20:20:04 +0300 Message-ID: References: <83h72r16g1.fsf@gnu.org> <640c2e07-98e1-96d6-bb02-19f5f03f637f@yandex.ru> <834jyq29o1.fsf@gnu.org> <92da07bd028e3ede61a6@heytings.org> <47894c57-dd8b-5778-240a-3fa6540e4d37@yandex.ru> <92da07bd02941d5537e9@heytings.org> <5308e3b5-a160-17d7-77ee-b1d00acfa20d@yandex.ru> <92da07bd02a6cc861e1a@heytings.org> <837d3lzv8n.fsf@gnu.org> <2c8d6755-cfe2-6559-3fde-3fa30ffb411e@yandex.ru> <83mtcgy44k.fsf@gnu.org> <83k07jx5jn.fsf@gnu.org> <866e510d-a060-7daa-d002-97861d056fa7@yandex.ru> <1144021660321893@iva5-64778ce1ba26.qloud-c.yandex.net> <12348081660379417@sas2-a098efd00d24.qloud-c.yandex.net> <66bbbb95983414e79637@heytings.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20084"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Cc: 56682@debbugs.gnu.org, Eli Zaretskii , monnier@iro.umontreal.ca To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Aug 13 19:21:26 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 1oMup9-0004wZ-Et for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 13 Aug 2022 19:21:23 +0200 Original-Received: from localhost ([::1]:59064 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oMup7-0004o0-SN for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 13 Aug 2022 13:21:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39302) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oMuop-0004ne-3r for bug-gnu-emacs@gnu.org; Sat, 13 Aug 2022 13:21:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:45259) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oMuoo-0004OG-8q for bug-gnu-emacs@gnu.org; Sat, 13 Aug 2022 13:21:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oMuoo-0006xt-4A for bug-gnu-emacs@gnu.org; Sat, 13 Aug 2022 13:21:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 13 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.166041121526681 (code B ref 56682); Sat, 13 Aug 2022 17:21:02 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 13 Aug 2022 17:20:15 +0000 Original-Received: from localhost ([127.0.0.1]:35008 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oMuo2-0006wH-Lb for submit@debbugs.gnu.org; Sat, 13 Aug 2022 13:20:15 -0400 Original-Received: from mail-wm1-f50.google.com ([209.85.128.50]:41622) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oMuo0-0006vy-JT for 56682@debbugs.gnu.org; Sat, 13 Aug 2022 13:20:13 -0400 Original-Received: by mail-wm1-f50.google.com with SMTP id az6-20020a05600c600600b003a530cebbe3so1919425wmb.0 for <56682@debbugs.gnu.org>; Sat, 13 Aug 2022 10:20:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc; bh=/GfBRBthfsl9wZH54OBZOuBOfWtr1S7L4d0Ka+scGlc=; b=epick3kHVj1JaOcJUfRT2nadlJTHtwg6x8NfehragS2pUsfINvwo8Qrw8JyGVsCbPV X6tYkh5xtVXa8Caj2xYQvwoputgOkUk4B87kiIib33kqjSc/MDxCrUmqxhtIe0nQQV1C +FDmUumdBdKalrpSm0WE805E/4J/MPpCBN5Og18obBjzF9A9pDJJppVi8TFFw3mRoDXr +x5C2rS46nHmXb23KZnuWlQhudBdTowhwut+ZFMh9Ky5mWu7g3zJi4Zl95cNm2WtC0/U 1Lx54GzN1moxE6OsUtgo5Ts6VZIvSXFd9jwA87yuy5aGFXTB/+D3y7j12JIHgr3twpQ1 h8cQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc; bh=/GfBRBthfsl9wZH54OBZOuBOfWtr1S7L4d0Ka+scGlc=; b=E107tzB+ggLI0vgYUe+j2Bpx83ACNiF9UsqlwdK0a04RaezWdEj4BSSfZXzNZy/8TA KMfgADCL3Sbsp5lPFkJprh18ClwOePzXA6R+9HI/9f9ryNwVoV1CTtssGBEUO0lo4YwG 63SEZib9H25i/Cg9cUsfbNHYlbiTr/5iyHPpy/pvz64QWIRWHi0+rKlL2g6OXC9N6ZT1 jD1tTeJc+UHwIaA1Q1+MxabOtRVxAUkGsq/0h6PhJN1bphEwLWZQQfXu3H6Wmvf8uxTJ jZ2BJUSpFg+NHyMXP2poOdhscWFlbm69eupCA/Hlt58BiukkjWpC62TkstoFvWMGpCBo TFXg== X-Gm-Message-State: ACgBeo3azRRRePepUJDyTY83VeVHq8hkC3Ag5O4dYnzdl66fnJNQl12k kiP3yt4cwpYwYxdzps/yUA0= X-Google-Smtp-Source: AA6agR6FtFzQUOUjGQ1T7pxhCa4x1L+OQacwEeiGGu/QxHK7OwZzkk5avIfilpq9dK/tMgkg00XuUA== X-Received: by 2002:a05:600c:35ca:b0:3a3:253b:708b with SMTP id r10-20020a05600c35ca00b003a3253b708bmr12410016wmq.86.1660411206715; Sat, 13 Aug 2022 10:20:06 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id p7-20020a1c5447000000b003a500b612fcsm3692597wmi.12.2022.08.13.10.20.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 13 Aug 2022 10:20:05 -0700 (PDT) Content-Language: en-US In-Reply-To: <66bbbb95983414e79637@heytings.org> 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:239572 Archived-At: On 13.08.2022 17:24, Gregory Heytings wrote: > >> >> But they're not. Of course, modes might have problematic rules >> (font-lock-keywords are turing-complete, after all), but it might be >> just as easy to fix all the main major modes rather than hobble user >> experience. >> > > You've made it quite clear that in your opinion incorrect font locking > hobbles user experience more than multi-second delays between motion or > search commands. I did not. As soon as the file becomes very large, such that font-lock actually becomes costly even in properly written major modes, we can still do one of the two things: apply narrowing during font-lock, or fontify only the beginning of the file. That's what two alternative values of font-lock-large-files (added on the branch) aim to do. But what is the good default value, and if it's not t, what thresholds to use, those questions require more testing and user feedback. >> Especially if we limit ourselves to modes that are likely to be used >> with large files. >> > > That's not the intention, no. > >> >> So please go ahead and experiment, and report on your findings later. >> > > I already did, and told you that these multi-second delays were still > present in larger JSON files (and therefore also in smaller files with > slower CPUs). Delays or "a delay"? Just the first time you scroll to EOB? Or did you do the whole dance with editing near BOB, then goto EOB, and repeat? Did you try that with other file formats? What is the size threshold where the performance becomes uncomfortable? >> Then the goal failed because we don't disable bidi hpa? It has a much >> more noticeable effect on editing that font-lock. >> > > That's not correct, no.  The BPA algorithm makes C-n and C-p slower at > the beginning of large files only in a very specific case: when the > beginning of the buffer contains opening brackets whose matching closing > bracket is at the end of the buffer. To be fair, that's pretty much all JSON files. But I can't quickly recall any other format with that properly, OK. > And the BPA algorithm does not > cause multi-second delays. The ones I saw seemed pretty bad. And they happened on every command invocation, not only after you edit the buffer on some distant position. And bidi-inhibit-hpa is the main cause of C-v/M-v stuttering over here. >>> Which is why fixing js-mode, and adding a json-mode, as you did, is a >>> "too local" fix. Of course, that doesn't mean what you did is >>> useless; it only means that it cannot be considered as a general >>> solution to the problem at hand. >> >> That's not what the branch contains. >> > > You're playing with words.  The fixes to js-mode and the added json-mode > are not on the branch because you installed them on master, but what you > claim the branch demonstrates depends on what you installed on master. > Or do you claim that what the branch contains makes editing any other > file (that is, not a .js or a .json file) almost as fast as what is on > master? The branch: 1) Allows everyone interested to evaluate the performance of unrestricted font-lock even in large files (single-line or not) and see how big on a problem the delays caused by syntax-ppss actually are in their experience. It's an important question. 2) Figure out the file sizes where syntax-ppss's performance really does become a problem. That can give us data for better defaults later. 3) Play around with two easy solutions that we discussed previously: narrowing during font-lock (one of the values for font-lock-large-files pretty much matches the current behavior on master), or fontifying only the first X characters (e.g. 1000000) of the buffer, and skipping on the rest. 4) It should be plain to see that implementing additional approaches should be easy enough. For instance, a hybrid like "fontify the first 1 MB correctly, and the rest - on best-effort basis". Although the value '(narrow . 1000000) should provide behavior a very similar behavior already. Maybe ever a better one: the boundaries are stable. Maybe sure to try it together with (setq bidi-inhibit-hpa t): the result looks very fast to me.