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 22:19:26 +0300 Message-ID: <0d67f253-c080-d750-c2cb-4a9591ff8c6c@yandex.ru> References: <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> <66bbbb95983475c5f3b0@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="6460"; 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 21:20: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 1oMwg6-0001Tk-Is for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 13 Aug 2022 21:20:10 +0200 Original-Received: from localhost ([::1]:37166 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oMwg5-0005L8-BB for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 13 Aug 2022 15:20:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57480) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oMwfy-0005Km-R2 for bug-gnu-emacs@gnu.org; Sat, 13 Aug 2022 15:20:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:45374) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oMwfy-0004K9-IT for bug-gnu-emacs@gnu.org; Sat, 13 Aug 2022 15:20:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oMwfy-0001RR-7Y for bug-gnu-emacs@gnu.org; Sat, 13 Aug 2022 15:20: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 19:20: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.16604183775504 (code B ref 56682); Sat, 13 Aug 2022 19:20:02 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 13 Aug 2022 19:19:37 +0000 Original-Received: from localhost ([127.0.0.1]:35123 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oMwfZ-0001Qh-5A for submit@debbugs.gnu.org; Sat, 13 Aug 2022 15:19:37 -0400 Original-Received: from mail-wm1-f42.google.com ([209.85.128.42]:54806) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oMwfY-0001QW-7M for 56682@debbugs.gnu.org; Sat, 13 Aug 2022 15:19:36 -0400 Original-Received: by mail-wm1-f42.google.com with SMTP id s23so2032475wmj.4 for <56682@debbugs.gnu.org>; Sat, 13 Aug 2022 12:19:36 -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=C+6LyK9RUIkVNUgJLRRHOQttCuGG0LG3q7Zdwvymo0g=; b=T7K8H+8Vh7EFeQCiqKUzLh6H1Ouk0U9M/jAFIiXvekmP+6HuOS0dfpj2hfwhw09dIU w71Hcc2P4iXEsU3XkodLXUsO89qlIwDVCdtmkhR3w8iwa+0119PZa1zchS9Z77P47fo6 q9Nj6DuZ1iMPLm0VboAJ0EvjFm4BQdEkkyvhpkLGi1ILef5mt5vssYfBY7fwH8oCHHpQ 7uD3zHLKts/ijviAuJeYz8Vpe5YhL1V37mjBo26qQTj1dAw6G7FXRksP3LdzTh5H4XkS 9F/gNPzzctrdxYh43UHHTrFFOm5wmUkA2zpV2cc5vG5tDAWRkOvclp9hH1ybyBK/MzcG JiQw== 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=C+6LyK9RUIkVNUgJLRRHOQttCuGG0LG3q7Zdwvymo0g=; b=rMgftofSzLc8kLWhgTtTbrhnEJt4FgDjIvKnL0EtGuiSEsLVjz7fxidIlzc18xxaq0 PFlcybyCYTnd2a/yEZUrb3tUSO6Pymie2LJUzxXQ/edUUMvmEAVPWx/TJPhrLSM/5w7s BagUJOT+upoE0U2PfeiGdYnk9JFarSqET2rsEVy6Kp3JLdsxwms8szuy0ycvnK+IHunz YOkaza032aO7v1ojtWvp8y+7QdDeEDlEidrN/ObVGenJJhfdieH34So89+JR4WwX1UtR 2Ulkb5/eOiL2FkYP/C6PGfLd3x6W4+9+mUV+DpwbMH1bCWPybpFGjltHYYbBIPi42KVp h+Gw== X-Gm-Message-State: ACgBeo0u7vDToj8pgnLgU9Qjg5xu4SxSwI5Tt3WgH/GglCDO8CUnNNRu ZbsaLW8Ahc8oxz74T2DScto= X-Google-Smtp-Source: AA6agR6o9YorTMKQf6WUiNS5fMzt4opVw2OfheRMlznFsk0nBQ730gMqoLC7ytMDtJvIT9E1ws7IGw== X-Received: by 2002:a05:600c:418a:b0:3a5:e724:21d4 with SMTP id p10-20020a05600c418a00b003a5e72421d4mr961895wmh.168.1660418370299; Sat, 13 Aug 2022 12:19:30 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id l14-20020a5d560e000000b0021f0558e51asm2695935wrv.55.2022.08.13.12.19.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 13 Aug 2022 12:19:29 -0700 (PDT) Content-Language: en-US In-Reply-To: <66bbbb95983475c5f3b0@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:239588 Archived-At: On 13.08.2022 20:43, Gregory Heytings wrote: > >>> 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? >> > > Delays.  When scrolling to EOB and when using isearch, for example. > >>>> 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. >> > > Again, the aim of this effort has _nothing_ to do with JSON files. What kind of files are your main target? >> 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. >> > > Buffers with long lines are rare enough.  It wouldn't make sense (and > would be a nightmare in terms of long term maintenance) to add 25 > defcustoms to allow anyone to fine-tune what Emacs does in such buffers. I have regularly encountered redisplay slowdown caused by long lines in my work. One doesn't need to have a 18 MB files to see them. Having a 5000-10000 character line is enough to see redisplay starting to stutter. And, of course, there's nothing font-lock related in those stutters. >> 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. >> > > These 3) and 4) assume that the major (and minor) modes are > well-behaving, and will obey the restrictions.  Which isn't true, and > was the reason why locked narrowing was introduced. What are your examples of misbehaving major/minor modes?