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: Tue, 2 Aug 2022 17:47:12 +0300 Message-ID: <668375bf-a861-04da-f78d-04b6719e0dd4@yandex.ru> 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> 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="14111"; 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 Tue Aug 02 16:48:31 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 1oItCB-0003Vz-G7 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 02 Aug 2022 16:48:31 +0200 Original-Received: from localhost ([::1]:39582 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oItC8-0005tf-Ix for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 02 Aug 2022 10:48:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55976) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oItBi-0005rW-Lf for bug-gnu-emacs@gnu.org; Tue, 02 Aug 2022 10:48:13 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54943) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oItBi-0001ra-C3 for bug-gnu-emacs@gnu.org; Tue, 02 Aug 2022 10:48:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oItBi-0000DC-92 for bug-gnu-emacs@gnu.org; Tue, 02 Aug 2022 10:48: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: Tue, 02 Aug 2022 14:48: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.1659451643568 (code B ref 56682); Tue, 02 Aug 2022 14:48:02 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 2 Aug 2022 14:47:23 +0000 Original-Received: from localhost ([127.0.0.1]:44692 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oItB4-000096-Rq for submit@debbugs.gnu.org; Tue, 02 Aug 2022 10:47:23 -0400 Original-Received: from mail-wr1-f53.google.com ([209.85.221.53]:45731) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oItB2-00008o-QR for 56682@debbugs.gnu.org; Tue, 02 Aug 2022 10:47:21 -0400 Original-Received: by mail-wr1-f53.google.com with SMTP id z16so18128336wrh.12 for <56682@debbugs.gnu.org>; Tue, 02 Aug 2022 07:47:20 -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=DaApA0QwvwLbPxtC7GpZpYkPIH0Q6qHNUTRZavh6bn8=; b=TuB9WxDXQrxRdlvFgZRWj6V3Grz6GsSQqGkN5IViNZb7IOZ0J4oPd91wP1fqV6cqvW nc4H5cvUIq+z+fYb2/oVDMSdoJe4s7senxau0unTaTOhK9ZmTV5W1QVMZxxDybrAKoa9 iUt9qK55D5vP257x3JXxRkXYS7h9SiwsXv/dagKt6WxW/tNGgroy8mCnj+Qe9UmckGx3 xYhVK63eU5U0SXy+duZydeG8l6cDn2bWkyLfomZ+A9V26TqGLg25Uw5k5HsVMQLhnt7t AFkm8he1fvcmqeaPsAgfdDLTB2ChV1sPJ6z215oCZBEtfISjklOAjjtPPUb2k1WLHIBc EMuw== 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=DaApA0QwvwLbPxtC7GpZpYkPIH0Q6qHNUTRZavh6bn8=; b=QQlBwuqSUfSYBfPhR36nvymmjfStDN+7+9WLF/bSXDdQfGC5+WECaj3XA2fYdd6y1q BsK8sj16sQhLY7Eoi9OJSfgha4LncqbtIc2WwXXKDFNL317K1pGAea8OKPmz2eYiZMEx wT+ItilGPkvSry/IhPM04XI8qI9XQZz/gqR1XQ+XwGg1AlrK2cyhP5EAsvDzjUnBKH+k f4y2p2x+IhiiqoozYc7vAjVljEtI7PBNP/O24PWCubEbIUz5i6JZ9/8dezD5zxxSFgx/ go+JoQ7A6hdwL9yWIUKmatG/PK0dwc0p2NaMoWVhk7HT7R/ArEUkCXqjooXgc0zECZ4R Jk/Q== X-Gm-Message-State: ACgBeo2D+GtiwwQ9PDOpXcqkMnbAZh56UAp7z8sz3dUnyoK3blDfdWSH pkiF+Rw7rkz85/6KkPFW6rA= X-Google-Smtp-Source: AA6agR72z7q3zE+lFQR/EbJjJb3zB/dUPsW+lmoniC1OqURRMGlgnrz3pk5446llwf4lIBYMqWYvjw== X-Received: by 2002:adf:eb92:0:b0:21e:ec16:8cbb with SMTP id t18-20020adfeb92000000b0021eec168cbbmr13105421wrn.282.1659451634798; Tue, 02 Aug 2022 07:47:14 -0700 (PDT) Original-Received: from [192.168.0.215] (buscust41-118.static.cytanet.com.cy. [212.31.107.118]) by smtp.googlemail.com with ESMTPSA id p5-20020a5d48c5000000b0020e6ce4dabdsm13279053wrs.103.2022.08.02.07.47.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Aug 2022 07:47:14 -0700 (PDT) Content-Language: en-US In-Reply-To: <83bkt27rij.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:238559 Archived-At: On 02.08.2022 15:35, Eli Zaretskii wrote: >> - 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. Interrupt it right after pressing 'M->'? Or at any time during editing the buffer later? 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. 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. >> 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. Whether they do or not, font-lock widens by default, see font-lock-dont-widen. >> 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. >> 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. >> 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. 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.