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: Wed, 27 Jul 2022 06:44:53 +0000 Message-ID: <05388e8d8812bfa3695d@heytings.org> References: <837d46mjen.fsf@gnu.org> <8a3eaeef01be5bfaa5ef@heytings.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="23887"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 56682@debbugs.gnu.org, Eli Zaretskii To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jul 27 08:45:37 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 1oGanY-000621-SZ for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 27 Jul 2022 08:45:36 +0200 Original-Received: from localhost ([::1]:55672 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oGanX-0000g0-FW for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 27 Jul 2022 02:45:35 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37884) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oGan0-0000f9-Ip for bug-gnu-emacs@gnu.org; Wed, 27 Jul 2022 02:45:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36966) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oGan0-0002U0-82 for bug-gnu-emacs@gnu.org; Wed, 27 Jul 2022 02:45:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oGan0-0008Pm-4s for bug-gnu-emacs@gnu.org; Wed, 27 Jul 2022 02:45:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Gregory Heytings Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 27 Jul 2022 06:45: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.165890429632320 (code B ref 56682); Wed, 27 Jul 2022 06:45:02 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 27 Jul 2022 06:44:56 +0000 Original-Received: from localhost ([127.0.0.1]:54948 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oGamu-0008PE-GE for submit@debbugs.gnu.org; Wed, 27 Jul 2022 02:44:56 -0400 Original-Received: from heytings.org ([95.142.160.155]:54542) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oGams-0008P2-Rt for 56682@debbugs.gnu.org; Wed, 27 Jul 2022 02:44:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1658904293; bh=lEcNF9jt5XKLPN9axq+NZHnZif6+Xd5SjRWlVLIbYko=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=8kGMgyZOkPfaJQOntstXOf/e2vh9zRKYD/XVd3yU1EFO2fFaixrJTmQoH7tvui5ob AfOF9RhzmE79q7YNHYhxtUbmWkIpgPnulX8nOMkydc44UgLV8I6ba6cWuvMif3lT6j 66YPUUS+IF37UpQUpv135TuKlt4MTajdnCfugOavsUX4Z4kVQBZ0jBDg8IOYU7MkhH qiGckRJXm55JkQVnCW6afnLjNiImIH5b4sia6OTDaThgObUTBxQ4lGjQ6+zaQEp5xT tPFmnhaNbOoeYGjjNFdpovYXkwZmc6KJqTRGFrGyW8BPsjinIDZPv9obcJZ4FL3M64 /BYiCibA3SAUQ== In-Reply-To: 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:238001 Archived-At: >>> Before using a blunt tool like the forced-narrowing now in >>> `feature/long-lines-and-font-locking`, I think we should try and >>> figure out *why* the recipe below is so slow. >> >> It's not a blunt tool, it's an appropriate tool to help making sure >> that Emacs remains responsive when large files are visited. > > I'm not opposed to reducing the size of the text that's considered, but > doing it via narrowing is a blunt tool. > It isn't. The only way to make sure that the size of the text is small enough is a forced narrowing from which fontification-functions cannot escape. But let's try to be constructive. You tell me that you're not opposed to reducing the size of the text, and that font-lock.el could enforce a smaller scope. So could you please design a (Elisp) function (in font-lock.el) which, given a (beg end) with beg <= end in a buffer, returns a (beg' end') with beg <= beg' <= end' <= end that are better starting end end points for the forced narrowing? That function would be run in handle_fontified_prop, before fontification-functions, and would have access to the whole buffer. >> Think of it as POSIX's ulimits. > > That's also a blunt tool. > It isn't either. It's a practical way to limit what a single process can do to make sure that what it does doesn't impact other running processes. At $job, each time I've seen a ulimit reached (usually the limit on open file descriptors), it was because of a bug. I think I've seen a single exception, with a program that sometimes really needed to open more (temporary) files. And even in that case the solution was not to remove the limit, but to raise it (from 1024 to 4096 IIRC). > > With the current narrowing they can't even know why the buffer is > narrowed and hence can't make an informed decision whether they should > maybe widen to look elsewhere. > There is no point to make such a decision, because they can't escape the narrowing.