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 10:45:49 +0300 Message-ID: <83a68k4fki.fsf@gnu.org> 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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26289"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 56682@debbugs.gnu.org, gregory@heytings.org, monnier@iro.umontreal.ca To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Aug 04 09:47:55 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 1oJVaE-0006dX-Uy for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 04 Aug 2022 09:47:55 +0200 Original-Received: from localhost ([::1]:59382 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oJVaD-0007kS-Pg for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 04 Aug 2022 03:47:53 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41248) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJVZO-0007jj-Tq for bug-gnu-emacs@gnu.org; Thu, 04 Aug 2022 03:47:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33052) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oJVZO-00060l-K6 for bug-gnu-emacs@gnu.org; Thu, 04 Aug 2022 03:47:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oJVZO-0004JT-Cg for bug-gnu-emacs@gnu.org; Thu, 04 Aug 2022 03:47: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 07:47: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.165959916616487 (code B ref 56682); Thu, 04 Aug 2022 07:47:02 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 4 Aug 2022 07:46:06 +0000 Original-Received: from localhost ([127.0.0.1]:51028 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oJVYU-0004Hq-5D for submit@debbugs.gnu.org; Thu, 04 Aug 2022 03:46:06 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:56448) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oJVYQ-0004HD-JJ for 56682@debbugs.gnu.org; Thu, 04 Aug 2022 03:46:05 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:35642) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJVYJ-0005wv-IU; Thu, 04 Aug 2022 03:45:56 -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=bQbVH5y+yk5VAcdCH+M6S1jyAAnY3ylwT5kRH98yJ1U=; b=J9pry+nHNweI 8cX7RVjiNV262wfn8yXvn3cvHquPyyXig7Qi1WM7vT8n7pZl8DKllG0nSA1IjipFEAAlga6D6QsiB yXibUufV2QqfdEMJfO3lqUPslwidpaWCopYMD3Bh4eQDMJoABw/+OQY7TZ82J72AA4+2SGmQfd2IY mYfDAZTjRj3qazSiTMYIuJK0W8XXi6Il90FvTD7WKqwJvLpE9SNZbS3fdRpXl03Jwia6BYLZwVDI+ ItOckBCnirwBVCz6NGAi7PGYxc1xJyDja4mxnZSBoi5RAoFDGZ4115nfxpVTvhwvH3L0Ma/9spboi YAimiwkjzvl2+ypZw+G9+g==; Original-Received: from [87.69.77.57] (port=4911 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 1oJVYH-00012B-Ne; Thu, 04 Aug 2022 03:45:55 -0400 In-Reply-To: (message from Dmitry Gutov on Thu, 4 Aug 2022 04:08: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:238691 Archived-At: > Date: Thu, 4 Aug 2022 04:08:20 +0300 > Cc: 56682@debbugs.gnu.org, gregory@heytings.org, monnier@iro.umontreal.ca > From: Dmitry Gutov > > > 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. So that behavior is unacceptable, but declaring we are unable to allow editing of such files is acceptable? If that is your position, we will have to agree to disagree. We have decided that we want a more graceful degradation in these cases, and in particular to sacrifice some accuracy of font-lock to allow reasonable editing of such files. If you consider that unacceptable, you can still have the lockups you prefer by setting long-line-threshold to nil. But we disagree with having nil be the default value of that variable. > > 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. I said "reasonably well", not "in fixed time". Some slowdown is acceptable. But when a simple editing operation takes several minutes, we cannot in good faith claim that Emacs is still usable. If you prefer to have that to some degradation in font-lock, then we disagree. > 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. The experience till now seems to indicate that the degradation caused by this solution is much milder and rarer than any other solution, and allows users to edit files with much longer lines. It certainly sounds like a better solution than completely disabling font-lock in such buffers (but that is still an option, if someone prefers it). Reporting specific problems with that solution will allow us to solve at least some of them, with the goal of making the degradation even more graceful -- this is what this bug report is for. But if you want to claim that it is better to have Emacs lock up for minutes in these cases, you will have to do that in your local customization, because we disagree with having Emacs behave like that when it can be avoided. > 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 directly related to the speed of operations. We didn't yet make any changes that affect large files in general, only files with long lines. In those cases, the speed of operations becomes unacceptably slow beyond some threshold, and we want Emacs to remain usable beyond that threshold, even if that makes fontifications sometimes inaccurate. > The long lines problem is caused by pathologic complexity of some > operations (like O(N^2) of line length, I guess). That assumption is incorrect, at least according to my analysis of the relevant bottlenecks. The slowdown is mostly linear in the number of buffer positions redisplay and its subroutines need to traverse. > 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. No one denies that beyond some threshold the performance will be too slow again. We just want to make that threshold much farther. In addition, the idea of using narrowing is a good one precisely because it is unaffected by the buffer size. So its effect doesn't deteriorate when the buffer or the line length becomes larger.