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:02:30 +0300 Message-ID: <83zggm63c9.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> <8c7321f2f36494299e61@heytings.org> <8c7321f2f336523624e3@heytings.org> <83r1202meh.fsf@gnu.org> <6020ffaf-9069-0070-76cf-a13379ef01b5@yandex.ru> <83les71ilg.fsf@gnu.org> <06c5560d-3009-e5a5-3d33-fe5d2ec32d6b@yandex.ru> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8505"; 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:06: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 1oIuQ1-0001y7-6t for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 02 Aug 2022 18:06:53 +0200 Original-Received: from localhost ([::1]:50228 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oIuQ0-0006ut-2s for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 02 Aug 2022 12:06:52 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57532) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oIuMI-00045i-C2 for bug-gnu-emacs@gnu.org; Tue, 02 Aug 2022 12:03:10 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55127) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oIuMI-0007bm-3T for bug-gnu-emacs@gnu.org; Tue, 02 Aug 2022 12:03:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oIuMH-0002Hf-SY for bug-gnu-emacs@gnu.org; Tue, 02 Aug 2022 12:03:01 -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:03:01 +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.16594561678754 (code B ref 56682); Tue, 02 Aug 2022 16:03:01 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 2 Aug 2022 16:02:47 +0000 Original-Received: from localhost ([127.0.0.1]:44876 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oIuM3-0002H8-8j for submit@debbugs.gnu.org; Tue, 02 Aug 2022 12:02:47 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:44538) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oIuM1-0002Gr-Bg for 56682@debbugs.gnu.org; Tue, 02 Aug 2022 12:02:46 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:47908) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oIuLv-0007U7-MC; Tue, 02 Aug 2022 12:02:39 -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=th+dt/ZXav+LJLK9mCIU74YeK+jt0SGd5QofudGe600=; b=Rn6pPOo1f/O0 Hc2RXPCH4z+VGOfCzDWL1V/13CZw42ZOKYyIXy8MDEQ/+LVhYVjJf0PXoxrZNtxvX2+MHqvm6jFL+ 9Akq3FYYyxtcHZX1cJsbRXNpotZceLdMJY4pDVIR3d8E2nUC0htzkPTTK/QCfFcvE6HQFs7HMk5/s bwHl7jawXfKc7Cpda2pyXBAuIjGoDnqCkVl9fg4RffMMzRfdmgsusbR7al4HHyRwzJJQPURAy1AQD fZSjSVK9oY+mKSetSP34mG6gDufqO+b3eXSuf4cAP0xbHrqTsf0DIO2OWc1Y3hT9Mo2rv27HAQe1M 8J3hTU4n/DJ124jGGks4WA==; Original-Received: from [87.69.77.57] (port=1750 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 1oIuLv-0004Pf-3c; Tue, 02 Aug 2022 12:02:39 -0400 In-Reply-To: <06c5560d-3009-e5a5-3d33-fe5d2ec32d6b@yandex.ru> (message from Dmitry Gutov on Tue, 2 Aug 2022 17:29:47 +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:238569 Archived-At: > Date: Tue, 2 Aug 2022 17:29:47 +0300 > Cc: monnier@iro.umontreal.ca, 56682@debbugs.gnu.org, gregory@heytings.org > From: Dmitry Gutov > > > IOW, in this case the Emacs developers, due to long-standing bug > > reports about this situation, recognized that it_can_ be improved, > > albeit in slightly unorthodox ways, and have taken the measures to > > optimize Emacs for the users. > > It would be a shame to have the better-behaving (faster) major modes > exhibit worse behavior that they could have because of the approach we > choose to solve the long-lines problem. Like I said: I'm okay with extending 'widen' to allow it to optionally break the lock on the narrowing. Then those modes which will indeed show reasonable performance in these cases can use that optional behavior. Otherwise, I think we've waited for such improvements in the modes long enough. > Regarding the long-standing bug reports, we did solve a bunch of issues > already. One major one, IIUC, was redisplay of already fontified text on > long lines. Another piece of the puzzle was added by Stefan in > 15b2138719b340. I invite you and Stefan to show that the improvement is performant enough in the cases we are using as examples of long lines. > So perhaps we should re-evaluate the testing scenario to see where the > current bottlenecks are. If we current main issue is the 55s spent in > syntax-ppss, a more constructive approach would be to look into > optimizing parse-partial-sexp. Or even give up on certain scenarios, > admitting that waiting 55s once to visit the end of a 1 GB buffer is not > so bad (and that could part could also be sped up by setting > syntax-propertize-function to nil and using a very simple syntax table, > for instance). I reported the problem with syntax-propertize to Stefan 1.5 month ago, see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45898#92. There was an improvement in that department, but AFAICT the net result is still unsatisfactory if you disable the recent long-line optimizations (e.g., by setting long-line-threshold to nil). So, unless I'm mistaken, the same scenario described there is still relevant, and doesn't yet need to be reevaluated. But more data points are always welcome, so feel free (you and everyone else) to test the performance with and without this feature, on different files with different major modes, and report back what you have found. At least I don't think the work on this is completed, we still have a lot of turf to cover and probably deal with fallout we haven't yet heard about.