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: Sat, 06 Aug 2022 10:28:24 +0300 Message-ID: <837d3lzv8n.fsf@gnu.org> References: <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> <74ddc877f17a06d8f120@heytings.org> <100d08b3-c25b-683f-6def-39052107ab59@yandex.ru> <83h72r16g1.fsf@gnu.org> <640c2e07-98e1-96d6-bb02-19f5f03f637f@yandex.ru> <834jyq29o1.fsf@gnu.org> <92da07bd028e3ede61a6@heytings.org> <47894c57-dd8b-5778-240a-3fa6540e4d37@yandex.ru> <92da07bd02941d5537e9@heytings.org> <5308e3b5-a160-17d7-77ee-b1d00acfa20d@yandex.ru> <92da07bd02a6cc861e1a@heytings.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3448"; 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 Sat Aug 06 09:29:15 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 1oKEFH-0000lQ-5c for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 06 Aug 2022 09:29:15 +0200 Original-Received: from localhost ([::1]:55486 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oKEFF-0007ML-KK for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 06 Aug 2022 03:29:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51000) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oKEF4-0007Ke-Sr for bug-gnu-emacs@gnu.org; Sat, 06 Aug 2022 03:29:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:43001) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oKEF4-0001IY-91 for bug-gnu-emacs@gnu.org; Sat, 06 Aug 2022 03:29:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oKEF3-0005JF-Uz for bug-gnu-emacs@gnu.org; Sat, 06 Aug 2022 03:29: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: Sat, 06 Aug 2022 07:29: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.165977092620388 (code B ref 56682); Sat, 06 Aug 2022 07:29:01 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 6 Aug 2022 07:28:46 +0000 Original-Received: from localhost ([127.0.0.1]:60983 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oKEEo-0005Im-De for submit@debbugs.gnu.org; Sat, 06 Aug 2022 03:28:46 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:38032) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oKEEk-0005IX-Dl for 56682@debbugs.gnu.org; Sat, 06 Aug 2022 03:28:44 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:60944) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oKEEY-0001HC-Ks; Sat, 06 Aug 2022 03:28:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=g4LMVIAIx7PQudVAmH2k5mkj0xuQP7FpEt/dU20VdWc=; b=KTViu8CU+MtcaEOZm5YB JJnbligiIk/M4W8vdShF5i3MzK5Zkl+w9hNp1mnt9wlQMZN2K7gAGj6qy110fo4LYEvaz2oj7wSKD 5kIVMFQjH5pB0NcmFdPVlsiedfy/zyAHDjjQMKYTB/99LMuE3g7bwwjludn5vnrzX/QC2OkDcz2US yT0bZq+v/7/Ck1+IovJmrZkmr3YBr/SFcJp9629TZGpRq80rXLcrCY1NE5ihTYCABs0LlwRcmJrfy y9IcXKC6ZPiYEN1S1ymoG8GvGH0c3llx5Th9C1Q1lrCSCI2lZMOYSZamPXK4UnTsKolkzxWKfcbCR Kh+trZmw7jJYYw==; Original-Received: from [87.69.77.57] (port=2416 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 1oKEEX-0006Om-Ho; Sat, 06 Aug 2022 03:28:30 -0400 In-Reply-To: (message from Dmitry Gutov on Sat, 6 Aug 2022 01:38:05 +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:238963 Archived-At: > Date: Sat, 6 Aug 2022 01:38:05 +0300 > Cc: 56682@debbugs.gnu.org, Eli Zaretskii , > Stefan Monnier > From: Dmitry Gutov > > > So what you prefer IIUC would be to call fontification-functions with a > > locked narrowing to 1 MB if point is before that threshold, and to not > > call fontification-functions at all after that threshold?  That might be > > another doable approach. > > If we have to support huge files with max responsiveness, then that > would be my preference, yes. > > I don't see the point of using a "locked" narrowing for this, though. > Maybe not even a narrowing at all: just avoid calling > fontification-functions with START > value_of(large_file_fontification_max). I don't understand why this would be a good idea. First, if we are able to fontify the first 1MB of a file, why won't we be able to fontify the 2nd, 3rd, ... Nth 1MB in a similarly fast fashion? Do you assume that fontification must go to BOB, but will never go forward towards EOB? Why would we make such an assumption, especially with long lines, where EOB could also be EOL? Next, why assume that your personal preferences in this case will be shared by everyone else? I, for one, will find it very strange to have font-lock suddenly disappear at an arbitrary point. If we don't want to make the assumption it will be good for everyone, your proposal should be one optional behavior, but not the only one. And finally, there's no way to restrict fontification-functions from accessing the buffer beyond the first 1MB, even if we want to, without something like the locked narrowing. > > emacs -Q > > M-: (setq long-line-threshold nil syntax-wholeline-max most-positive- > > fixnum) RET > > C-x C-f dictionary.json RET y ;; takes 160 seconds > > C-e ;; takes 200 seconds > > > > emacs -Q > > M-: (setq long-line-threshold nil) RET > > C-x C-f dictionary.json RET y ;; immediate > > C-e ;; not finished after 1200 seconds (20 minutes), I killed Emacs > > I get what you're saying, but the approach does seem "right" to me > because it works, letting me view and edit dictionary.json with good > performance and behavior. On a Core i9 machine and with an optimized build, I presume? And with "good" being your subjective judgment that places more importance on fontification than on responsiveness? That's not necessarily a good data point on which to base our decisions regarding the default behavior. > Either way, I believe the change is at the right level of abstraction, > and if it has bugs, they should be solvable without major redesign. Alas, Mr. ShouldBe is not available for this project, and probably won't be any time soon.