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 15:35:00 +0300 Message-ID: <83bkt27rij.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28052"; 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 14:36:36 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 1oIr8W-000763-7j for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 02 Aug 2022 14:36:36 +0200 Original-Received: from localhost ([::1]:60396 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oIr8V-0002D7-AF for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 02 Aug 2022 08:36:35 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44920) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oIr7y-0001p7-Ov for bug-gnu-emacs@gnu.org; Tue, 02 Aug 2022 08:36:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:53038) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oIr7y-0002Lm-8w for bug-gnu-emacs@gnu.org; Tue, 02 Aug 2022 08:36:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oIr7y-0000TL-4r for bug-gnu-emacs@gnu.org; Tue, 02 Aug 2022 08:36: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 12:36: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.16594437291754 (code B ref 56682); Tue, 02 Aug 2022 12:36:02 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 2 Aug 2022 12:35:29 +0000 Original-Received: from localhost ([127.0.0.1]:42784 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oIr7Q-0000SE-Ha for submit@debbugs.gnu.org; Tue, 02 Aug 2022 08:35:29 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:60108) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oIr7O-0000S0-Mk for 56682@debbugs.gnu.org; Tue, 02 Aug 2022 08:35:27 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:44112) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oIr7J-00028n-Dm; Tue, 02 Aug 2022 08:35:21 -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=0xIw/AAKfIDtzJqdqxDNOK7dG8QoU9iWz5mP1VW2Ioo=; b=kuSGQ8OFmsVA 9oH1+pn/ytXx3buB61g5s+pREjU9YwNveG/YkfSPzJPrKlw7wIUxHoWHQjchH49JbT2QRsvZomghU LWvFoUw+AKmenCaeAvQmzlYL7eyzjYPAmqLSxyAtnvptfSBbT4+ntxqWhegAnmj3alboXIB5QdVws Oe59LA4azJ/tSZ3P19Pw2yRxemIiPdqJDezqVRoi6bNA8KE3H2ooIQJwAyGg8eOUCDZELTMVzUqPV psQ+S6wSZN+7w8Cuxhm9dxBel+QnSVMUEdxc5jKefredCQvJUiydq+z4c5fw5rcGvd9WGaETFpoLr xfHwguZbYiNCTJcnI+ySfQ==; Original-Received: from [87.69.77.57] (port=4856 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 1oIr79-0000zY-LE; Tue, 02 Aug 2022 08:35:21 -0400 In-Reply-To: <17c0d4df-78f5-76f4-784d-5c9d52eb7fa0@yandex.ru> (message from Dmitry Gutov on Tue, 2 Aug 2022 04:05:57 +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:238548 Archived-At: > Date: Tue, 2 Aug 2022 04:05:57 +0300 > Cc: 56682@debbugs.gnu.org, gregory@heytings.org, monnier@iro.umontreal.ca > From: Dmitry Gutov > > >> The alternative being that font-lock would call syntax-ppss right away > >> with no restriction, but then only apply highlighting to limited parts > >> of the buffer. > > > > AFAIU, this seems to assume that highlighting is much faster than > > syntax-ppss. Is that a given? If not, I don't think I understand how > > this could help. > > I don't have the concrete numbers at hand, but from experience I'd say: > > - syntax-ppss over the whole buffer is fast-ish. But it takes O(N) time > of course, and the bigger the buffer is, the longer it'll take. Not much > we can do about it. > - font-lock has to do more work, so over the whole buffer it will take > an order of a magnitude more time than syntax-ppss. > > Further: > > - syntax-ppss is also important for correctness: for commands to > understand whether the point is inside a string, comments, etc. So it's > better to avoid applying narrowing when calling it. Unless you're in a > multiple-major-modes situation. > - font-lock calls syntax-ppss. 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. > So ideally font-lock is either called with undo-able narrowing, or is > simply passed a range of positions, and shouldn't fontify too far from them. Many major-modes do widen the buffer, though. > 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. > 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? > IOW, IIUC the fix for font-lock performance could be better implemented > inside font-lock itself, as long as all the info about whether the > current line is "long" is available to Lisp. 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.