From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings Newsgroups: gmane.emacs.bugs Subject: bug#56682: Fix the long lines font locking related slowdowns Date: Sun, 31 Jul 2022 14:09:19 +0000 Message-ID: <8c7321f2f3da85d0489e@heytings.org> References: <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> <83y1wa4e6q.fsf@gnu.org> <65cb7c73fdbf1de53ea7@heytings.org> <83tu6x4xis.fsf@gnu.org> <8c7321f2f3859b5ee60b@heytings.org> <83k07t4pre.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38028"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gerd.moellmann@gmail.com, 56682@debbugs.gnu.org, larsi@gnus.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 Sun Jul 31 16:10:11 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 1oI9dy-0009bR-P3 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 31 Jul 2022 16:10:10 +0200 Original-Received: from localhost ([::1]:52912 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oI9dw-0002Qj-OD for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 31 Jul 2022 10:10:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45686) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oI9dq-0002Qb-GP for bug-gnu-emacs@gnu.org; Sun, 31 Jul 2022 10:10:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:48688) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oI9dq-000524-77 for bug-gnu-emacs@gnu.org; Sun, 31 Jul 2022 10:10:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oI9dp-0000u5-Vo for bug-gnu-emacs@gnu.org; Sun, 31 Jul 2022 10:10:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Gregory Heytings Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 31 Jul 2022 14:10: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.16592765633416 (code B ref 56682); Sun, 31 Jul 2022 14:10:01 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 31 Jul 2022 14:09:23 +0000 Original-Received: from localhost ([127.0.0.1]:38437 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oI9dD-0000t2-Ep for submit@debbugs.gnu.org; Sun, 31 Jul 2022 10:09:23 -0400 Original-Received: from heytings.org ([95.142.160.155]:60592) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oI9dB-0000st-E3 for 56682@debbugs.gnu.org; Sun, 31 Jul 2022 10:09:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1659276560; bh=wos+TLxhixLq5BUXqzr3wdnoj3lDhFTH1QIisqMDhCM=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=B3ygdvnqnJXtH4mo5TuCxOwx6xPNK0NWO+p6WCblaaqP7EAY9eONb8hS9VlkgsUL+ 0YYbZQou3S0yb5S8MtOk7mb4nKcPraoZ/dRwKnCi8TZMDyV0dkzdGr5m2puCLZ5fsU lK9+a7OFohu2QJyBpTPG687nP7uuZmRZ3D3Vb2nwxtUxMRHHvUskdRSz4IRhOVeK0E ttNhCaIphqC0D+153lk6S0Z+wFw9FO175hno59SB6OXiIRSwM+yYjRMP2ms5Ls5epk eOhKIO8Kirz6MH85CgYtDiJCs+casvjpuSVBIR1iGi/jxDIrPekvhatSRdIGlAGtjd PoMc/spSKVUzg== In-Reply-To: <83k07t4pre.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:238345 Archived-At: > > And since we already remove expensive hook functions, maybe that is > enough? Or maybe we should use a different threshold for "expensive" in > buffers with long lines? > Do we? As far as I can see, there is no time limit in safe_run_hooks. It could make sense to add one (or at least to clear out hook functions that have taken too long, as we already do it with functions that return an error... but doing that after the hook function returns is already too late, if it has taken say 30 seconds). >>> Well, WDYT about a similar feature for very large files? IOW, when >>> the buffer's size is above some threshold, turn on the >>> long_line_optimizations_p flag (which should perhaps be renamed to >>> better reflect its purpose) even if no long lines are seen? >> >> I was thinking about such a feature indeed. But it would be separate >> from the long_line_optimizations_p one, because the optimizations to >> activate in both cases are different, and their thresholds are >> different, too. > > Different thresholds are easy to reconcile: the optimizations should be > turned on if either of the two thresholds is exceeded. But why do you > say the optimizations will be different? what's wrong with using the > same optimizations, i.e. restrict the display code from accessing the > entire buffer? > I don't know exactly yet. It seems to me that some of the optimizations for large buffers would be similar to the ones for long lines, and that many of the specific optimizations for long lines are not necessary for large buffers. I think it would be better/safer to only enable the optimizations that are really necessary in each case. But let's start thinking in more detail about the large buffer optimizations once the long lines optimizations are done, okay?