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: Tue, 02 Aug 2022 19:11:53 +0300 Message-ID: <83y1w662wm.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> <56a688f6-6c93-8b67-895c-2c41f563fc93@yandex.ru> <83sfmg2mkv.fsf@gnu.org> <17c0d4df-78f5-76f4-784d-5c9d52eb7fa0@yandex.ru> <83bkt27rij.fsf@gnu.org> <668375bf-a861-04da-f78d-04b6719e0dd4@yandex.ru> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40956"; 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 Tue Aug 02 18:13:18 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 1oIuWC-000AUh-BU for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 02 Aug 2022 18:13:16 +0200 Original-Received: from localhost ([::1]:33414 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oIuWB-0006EN-3C for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 02 Aug 2022 12:13:15 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33160) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oIuVy-0006BB-IZ for bug-gnu-emacs@gnu.org; Tue, 02 Aug 2022 12:13:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55141) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oIuVy-0001pv-9W for bug-gnu-emacs@gnu.org; Tue, 02 Aug 2022 12:13:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oIuVy-0002WU-5A for bug-gnu-emacs@gnu.org; Tue, 02 Aug 2022 12:13: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: Tue, 02 Aug 2022 16:13: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.16594567339617 (code B ref 56682); Tue, 02 Aug 2022 16:13:02 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 2 Aug 2022 16:12:13 +0000 Original-Received: from localhost ([127.0.0.1]:44886 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oIuVB-0002V2-2z for submit@debbugs.gnu.org; Tue, 02 Aug 2022 12:12:13 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:48160) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oIuV5-0002Uk-PM for 56682@debbugs.gnu.org; Tue, 02 Aug 2022 12:12:11 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:48226) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oIuUz-0001Wd-9u; Tue, 02 Aug 2022 12:12:01 -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=MedbFzJddfX09oB3nkT7Mv//7fVXOo6K2hgXaKMhXf4=; b=e4Eho77L6I3L AkMyMbk+opfMNOy5nPB6pMN5f/6xS6rpUeCq7CiuAGgtkRI0tMDkRJyNygcDWJ8IRFJTAf/Kg7BP6 SugKsQ+Qw0XXQpnYc5Ijqg6SYJhIM358YMXTh3oyw6yv5FV4nuKat9FmHbXIJyhWJUB2rSDdpWPVO Vmk2S87EitxOT5FxwzGSjOD+JmI64d4d0qWBTqxN0Ze10xABytWH5v7F88u/7MlcyYrs2FT7xWvzD r1+BZyZMar3pxTQD9ucgod/yj4D1CKco3UOxPuWY8tp3qRMtLDjh+IhsrEcG53tzHaa4YXTVabwVI rdJ1DQ6y7Zm+/ZJ5yA+AFw==; Original-Received: from [87.69.77.57] (port=2321 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 1oIuUy-0006t5-PT; Tue, 02 Aug 2022 12:12:01 -0400 In-Reply-To: <668375bf-a861-04da-f78d-04b6719e0dd4@yandex.ru> (message from Dmitry Gutov on Tue, 2 Aug 2022 17:47:12 +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:238570 Archived-At: > Date: Tue, 2 Aug 2022 17:47:12 +0300 > Cc: 56682@debbugs.gnu.org, gregory@heytings.org, monnier@iro.umontreal.ca > From: Dmitry Gutov > > > I believe I was talking about syntax-ppss being called from font-lock, > > indeed. Before Gregory's changes, if you visit a large file with very > > long lines, and interrupt Emacs while it is non-responsive, you will > > in many/most cases find yourself in syntax-propertize or its > > subroutines, and you will see that it is almost always called to > > traverse the entire long line. > > Interrupt it right after pressing 'M->'? Or at any time during editing > the buffer later? Just after "C-x C-f" and answering YES to the question whether to visit it normally. > The latter really shouldn't happen. If it does, perhaps it's the result > of narrowing during redisplay, which might blow syntax-ppss's caches. I'm talking about running with narrowing disabled. > In any case, if you could point to a scenario and the revision to test > it on, I'll be sure to take a look. See my other message I sent a few minutes ago. And I believe Gregory also pointed to it. > > Many major-modes do widen the buffer, though. > > Whether they do or not, font-lock widens by default, see > font-lock-dont-widen. Which is a breach of contract with jit-lock, if you ask me. It's no accident that jit-lock invokes fontification-functions only on a small region of the buffer: that's how this feature was designed and implemented, and its entirely consistent with the overall design of the basic principle of the Emacs display engine: examine only as much of the buffer as needed to be displayed. > >> The latter seems to be the case already (if you open xdisp.c and press > >> M->, only top and bottom of the buffer are fontified) > > > > It is not enough to look for faces in order to realize how much of the > > buffer was scanned. > > I evaluated (next-single-property-change 1 'fontified), when near BOB > and when near EOB. That's not enough either. Try running under a debugger with a watchpoint on the position point, while fontification-functions run, and be amazed how many time it moves point waaay out of the region that is about to be displayed. > >> with the caveat that font-lock always tries to backtrack to BOL when > >> fontifying the current hunk. Which makes sense, of course, but could > >> be tweaked for long lines to avoid re-fontifying the whole buffer > >> again and again. > > > > "Tweaked" how? > > 15b2138719b34083 is one example. It's a good improvement, but much more is needed. Again, why don't you try this yourself, after disabling the recently added optimizations? > > No one will object to making font-lock faster. But the experts who > > can do that are few and far in-between, and seem to have other itches > > to scratch, since these issues are known for a long time, and several > > times were even discussed at length. > > The fact that we have +1 contributor to the C part of Emacs (the display > engine, etc), and a successful one at that, does nothing about the fact > that Lisp is easier to write and debug. > > If we're able to demonstrate that the remaining bottlenecks are inside > font-lock, it should be easier to improve there. And it will be very easy to disable these optimizations by default when we decide that they are no longer needed. Meanwhile, Emacs users get to edit long lines with reasonable performance.