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: Thu, 4 Aug 2022 04:08:20 +0300 Message-ID: References: <837d46mjen.fsf@gnu.org> <8a3eaeef01be5bfaa5ef@heytings.org> <05388e8d8812bfa3695d@heytings.org> <83v8rf5894.fsf@gnu.org> <65cb7c73fd4a999cca00@heytings.org> <8c7321f2f3400a5db9be@heytings.org> <8c7321f2f388e5343475@heytings.org> <6ea376f6-d503-06d8-6d83-50c52b695394@yandex.ru> <8c7321f2f3ac52bfee4b@heytings.org> <2f7eeea3-6ba9-d2c2-1fb9-dd40d2de2002@yandex.ru> <8c7321f2f368e8dd096d@heytings.org> <83tu6w2mrm.fsf@gnu.org> <83les82jz1.fsf@gnu.org> <83fsig2ja2.fsf@gnu.org> <83mtcn1isf.fsf@gnu.org> <83b48a42-671a-98d0-da05-1804787db8c8@yandex.ru> <8335ee7imr.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30710"; 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, gregory@heytings.org, monnier@iro.umontreal.ca To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Aug 04 03:09:39 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 1oJPMo-0007ne-RZ for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 04 Aug 2022 03:09:38 +0200 Original-Received: from localhost ([::1]:52900 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oJPMn-0001eO-Uh for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 03 Aug 2022 21:09:37 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58140) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJPMF-0000bB-6I for bug-gnu-emacs@gnu.org; Wed, 03 Aug 2022 21:09:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:60785) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oJPME-00026I-UY for bug-gnu-emacs@gnu.org; Wed, 03 Aug 2022 21:09:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oJPME-00063j-Lm for bug-gnu-emacs@gnu.org; Wed, 03 Aug 2022 21:09: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: Thu, 04 Aug 2022 01:09: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.165957532523261 (code B ref 56682); Thu, 04 Aug 2022 01:09:02 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 4 Aug 2022 01:08:45 +0000 Original-Received: from localhost ([127.0.0.1]:50533 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oJPLx-000636-7R for submit@debbugs.gnu.org; Wed, 03 Aug 2022 21:08:45 -0400 Original-Received: from mail-wr1-f49.google.com ([209.85.221.49]:34560) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oJPLh-00062Q-5r for 56682@debbugs.gnu.org; Wed, 03 Aug 2022 21:08:43 -0400 Original-Received: by mail-wr1-f49.google.com with SMTP id j1so15132558wrw.1 for <56682@debbugs.gnu.org>; Wed, 03 Aug 2022 18:08:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=PR1XnexcLXHfbboCj6cE9mmXVyvlY3tgoxv/qnKjp64=; b=Qq34CG1fEa6eO8AnmCarBYnT/zef1TXBvlED/8WQjt7lBz9lbbg9vUTbGisiHNE/e1 qcK6tNFGwYqKLN82wXOjFGtXO0VMizAlnHerMytzd88hFmyJbO3MwBSdHIoj/HgSkoAe 40SH1CLH68VEOxQ603v3LdmD808gqD0IAX8JbxpM8AnpiOymFT2SjSIwdgVA1wQEd+fi t6fGRHLBFdJKEyeFuZEwnghEl2dxvWt0h0HEG7e4UyCFBBti4ImUa7hscu3hltb/KgUb AznehlHy0PhWYd+4Y2sb+zqXxQCNBZtfZIAZh2SDNbnMIw9SlA6uvaOFHrzy0h++8xrF FXvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:message-id:date:mime-version:user-agent :subject:content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=PR1XnexcLXHfbboCj6cE9mmXVyvlY3tgoxv/qnKjp64=; b=L4CeHBY4PIhf30N9RHis5a7oKBwA5m4QcqplHyoG/A6ugi3miwZC1XvKbBwUO5kqxk oOIBjmH83OhZw1jLhh3IISpF2L3s8hv7XebKoIjCPKC7ycROCYjPWxJ35sR98VMzLcWC hghbNFTZf4frwKqsWFrFQ0OlpTmMsarl1mKZ5vwU9jEv4y5fs/VnlKHNYhAhsOAaELsS TSicbHC94O9odlW3oMI0qvZN2QsegzDCTsQyeLDVu4VaIoPWcfdyArgI/WmGJks0XCLS NxsDJu1792vDbNBwVthq9BcqEdEjfrDT5TCh6rX2rMUR2xVrkzv4qs4FhdsZiltudBjp uUsg== X-Gm-Message-State: ACgBeo3+pq2l3i+jEqsNb9k662Qy+YnUkO1gBQBW2/YjYFriMAJAa6cJ 7Nvw1T9X/IUoHtsf6OulSl0= X-Google-Smtp-Source: AA6agR6yojd6Xv7lmiqI7idjO2+ElhHySuzB9vuym/4ljNReQc2gKWhpHbPE/A9vvrKw3p4OYbAKtA== X-Received: by 2002:a5d:5985:0:b0:21d:b6aa:23f5 with SMTP id n5-20020a5d5985000000b0021db6aa23f5mr18032624wri.18.1659575302430; Wed, 03 Aug 2022 18:08:22 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id d14-20020adfef8e000000b0021d6dad334bsm19404601wro.4.2022.08.03.18.08.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Aug 2022 18:08:22 -0700 (PDT) Content-Language: en-US In-Reply-To: <8335ee7imr.fsf@gnu.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:238663 Archived-At: On 02.08.2022 18:46, Eli Zaretskii wrote: >> Date: Tue, 2 Aug 2022 17:10:53 +0300 >> Cc: 56682@debbugs.gnu.org, gregory@heytings.org, monnier@iro.umontreal.ca >> From: Dmitry Gutov >> >> On 02.08.2022 05:27, Eli Zaretskii wrote: >>>> syntax-ppss cache is a list of checkpoints spread along the buffer. >>>> >>>> After a modification, only the checkpoints below it are invalidated (to >>>> be recomputed on-demand later). >>> So a suitably-concocted replace command will still invalidate a lot of >>> that cache, right? >> >> For any cache, one can invent an operation that would result in >> thrashing it repeatedly. > > Yes, but when thrashing causes delays of dozens of seconds, the result > is not just a rare delay, the result is simply unacceptable. What is unacceptable is the behavior I see from the narrowing solution. See the screenshots I attached in this thread. >> A regular search-replace should work well enough, though. Because when >> the buffer is long, the user is likely, on average, to spend a lot more >> time examining the occurrences and deciding whether to replace each one. >> And since the operation goes from top to bottom, this will likely >> invalidate the list of caches once, and then rebuild it from the >> beginning (or from wherever the first replacement was). > > We want every basic operation in such buffers to perform reasonably > well. That's the goal of this activity. Because partial solutions > that sometimes work we already have: there's so-long-mode, there's > longlines.el, and a couple of other trick up our sleeve. We cannot perform every basic operation in fixed time for any arbitrarily sized file. There are limits of what we can possibly do. If we narrow willy-nilly, we step on the toes of syntax parsing and get other weird behaviors as a result. Which means we got another partial solution. so-long-mode, longlines, etc, were all targeted as buffers with long lines. I'd really like it if we could scope this discussion to solving that particular problem. Not the speed of operations in large files in general. The long lines problem is caused by pathologic complexity of some operations (like O(N^2) of line length, I guess). syntax-ppss's performance is nothing like that: it's O(N) for initial full scan, and O(1) for most operations afterward. You can't really get better than that. Maye get a better multiplier with tree-sitter or a more optimized version of parse-partial-sexp, but take a 10x bigger file (or 100x bigger, or 1000x bigger) - and voila, the delay can be observed again.