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, 30 Jul 2022 22:02:05 +0300 Message-ID: <83y1wa4e6q.fsf@gnu.org> References: <83zggwcby5.fsf@gnu.org> <83o7xccagi.fsf@gnu.org> <831qu7daxb.fsf@gnu.org> <83sfmnb7yg.fsf@gnu.org> <837d3ybh5z.fsf@gnu.org> <136c4fe0fc74196714aa@heytings.org> <83pmhp89ov.fsf@gnu.org> <136c4fe0fc39573addc9@heytings.org> <83k07x8738.fsf@gnu.org> <136c4fe0fcdf00ef9a11@heytings.org> <83h73183r7.fsf@gnu.org> <136c4fe0fc0fceb0d752@heytings.org> <838roc8ka7.fsf@gnu.org> <83tu706obt.fsf@gnu.org> <83h7306ifa.fsf@gnu.org> <83edy37pul.fsf@gnu.org> <83pmhn55sk.fsf@gnu.org> <65cb7c73fdc753518d35@heytings.org> <83fsii68o3.fsf@gnu.org> <65cb7c73fdf6704d19d5@heytings.org> <835yje62vz.fsf@gnu.org> <65cb7c73fd159efe32af@heytings.org> <83zggq4fgb.fsf@gnu.org> <65cb7c73fd6ca16565e1@heytings.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2186"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gerd.moellmann@gmail.com, 56682@debbugs.gnu.org, larsi@gnus.org, monnier@iro.umontreal.ca To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jul 30 21:03:21 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 1oHrk8-0000OI-Ps for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 30 Jul 2022 21:03:21 +0200 Original-Received: from localhost ([::1]:58198 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oHrk6-0005L3-QI for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 30 Jul 2022 15:03:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55268) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oHrjq-0005KC-93 for bug-gnu-emacs@gnu.org; Sat, 30 Jul 2022 15:03:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:46016) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oHrjq-0008VZ-0x for bug-gnu-emacs@gnu.org; Sat, 30 Jul 2022 15:03:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oHrjp-0000z1-P9 for bug-gnu-emacs@gnu.org; Sat, 30 Jul 2022 15: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: Sat, 30 Jul 2022 19: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.16592077613744 (code B ref 56682); Sat, 30 Jul 2022 19:03:01 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 30 Jul 2022 19:02:41 +0000 Original-Received: from localhost ([127.0.0.1]:35765 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oHrjR-0000yE-OO for submit@debbugs.gnu.org; Sat, 30 Jul 2022 15:02:41 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:42312) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oHrjG-0000xk-1n for 56682@debbugs.gnu.org; Sat, 30 Jul 2022 15:02:36 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:40490) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oHrjA-0008T9-EI; Sat, 30 Jul 2022 15:02:20 -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=hPXEIF0yIX7LglQ4XZkuh4wW2VRhyqhjLRt45iFTkvQ=; b=QLAhDi3Uf60H hQmTKXXutdzThaudIEsRPawninXPsgKxA9pBWi+bBqEddyYUDgQHqB65JoNbHBGpd5ZqS5YiPjsZX 6AuSaoLkK9XQHydenD1RG29d/4jDmX0DO6d9TjINcTfUHG8UKT8C+hpd3wSCuYrR7lv02E5TGyCaQ eB7YvbJfYfi+Ltywu8YLkzRXk0J0bHtg43TdytValebbNpNxYg3XP9z6T3VBKI5Bh9rT45drl4Tmh DWE+wyd5UfoayB19U896KW2HEmwLLbCsOLswGdwlx+zFy8OOf0xE85GB5aM5RYvurUaO45O7KYTEC dnJF5r0gDEBSUtp87KeZkg==; Original-Received: from [87.69.77.57] (port=2007 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 1oHrj9-0004Fx-TA; Sat, 30 Jul 2022 15:02:20 -0400 In-Reply-To: <65cb7c73fd6ca16565e1@heytings.org> (message from Gregory Heytings on Sat, 30 Jul 2022 18:47:04 +0000) 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:238309 Archived-At: > Date: Sat, 30 Jul 2022 18:47:04 +0000 > From: Gregory Heytings > cc: gerd.moellmann@gmail.com, 56682@debbugs.gnu.org, larsi@gnus.org, > monnier@iro.umontreal.ca > > >> Wouldn't it make sense to also limit the portion of the buffer to which > >> pre-/post-command-hook have access (see below)? > > > > Those generally don't belong to the display department, so I'd hesitate > > doing so. Which pre-/post-command-hook functions did you find that > > cause slowdown because of long lines. > > jit-lock--antiblink-post-command OK, but is it TRT to "punish" every one of these hooks for the "crimes" of the few? Maybe we should instead handle the problematic ones locally, by exposing the long_line_optimizations_p flag to Lisp (through an accessor), and then modifying those that misbehave to "behave"? > >> With that patch, I was able to open and edit a file with a single 50 GB > >> (!) line, in js-mode. Does that still not qualify as "arbitrarily > >> large"? > > > > We don't even claim to be able to edit _files_ of arbitrary size > > (because we are limited by fixnums). > > That's theory, isn't it? With 64-bit builds we are limited to files that > are less than 2047 Po. No computer on this planet has that much RAM. You forget that we are talking about VM. But let's not restart that argument, okay? > >> I compared that with a 50 GB JSON file with 80 character wide lines. > >> With that file it was necessary to disable font-lock-mode, which took > >> too much time. > > > > How so? We now restrict font-lock to a small region, so why does it > > matter how much more stuff is there outside of the viewport? What other > > aspects of the line size still affect performance? > > > > We do not restrict font-lock in large files _without long lines_, hence > the difference. Sorry, I thought you were talking about a single-line file. If JS mode wants to access the entire buffer for fontifications, then IMO the problem is in JS mode, and should be fixed there. narrow-to-region is available to Lisp programs as well ;-) IOW, it isn't an infrastructure problem that needs to be fixed in display code. (It is even possible that tree-sitter integration will fix this, or at least alleviate it, as a side effect.)