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: Wed, 27 Jul 2022 05:41:52 +0300 Message-ID: <83r127b7kf.fsf@gnu.org> References: <837d46mjen.fsf@gnu.org> <174616cd5c33bfc14b1f@heytings.org> <837d44jr4p.fsf@gnu.org> <83bktghrn0.fsf@gnu.org> <8a3eaeef010995a5da8d@heytings.org> <837d40ds09.fsf@gnu.org> <83zggwcby5.fsf@gnu.org> <83o7xccagi.fsf@gnu.org> <831qu7daxb.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9210"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gerd.moellmann@gmail.com, 56682@debbugs.gnu.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 Wed Jul 27 04:42:10 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 1oGWzy-0002Fc-3x for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 27 Jul 2022 04:42:10 +0200 Original-Received: from localhost ([::1]:46986 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oGWzw-0004Xp-GF for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 26 Jul 2022 22:42:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58820) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oGWzq-0004XR-86 for bug-gnu-emacs@gnu.org; Tue, 26 Jul 2022 22:42:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36715) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oGWzp-0003vE-SZ for bug-gnu-emacs@gnu.org; Tue, 26 Jul 2022 22:42:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oGWzp-0000sX-MY for bug-gnu-emacs@gnu.org; Tue, 26 Jul 2022 22:42: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: Wed, 27 Jul 2022 02:42: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.16588897153365 (code B ref 56682); Wed, 27 Jul 2022 02:42:01 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 27 Jul 2022 02:41:55 +0000 Original-Received: from localhost ([127.0.0.1]:54697 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oGWzi-0000sB-G1 for submit@debbugs.gnu.org; Tue, 26 Jul 2022 22:41:55 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:45860) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oGWzg-0000ru-T3 for 56682@debbugs.gnu.org; Tue, 26 Jul 2022 22:41:53 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:51352) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oGWza-0003sS-P2; Tue, 26 Jul 2022 22:41:47 -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=duTNsMir0GObcsNrC5DaruUyuZMb/HODzWy6Fq5yBkw=; b=K6cki6mUIbq2 Glt+hK3yDgS/V5ldW9VdH8Jn3FwjUlXsTyS8Q2PeOLVBDVgoMVqiI4GnbZAkGcbLiZl7jVoMUFHVS o5vKBCSy13D0uzEvtJ05QsIA2+H46rAhvVaZ9Z2zt2CxOSEaCVLzHOZWsK1/ta8v68k6r8mgyTLX8 SMXWn03z3WFRkxb39tHFzD6TNnFx/kuQfQDXkKLb9fI4bky4P1+XzaNQCe+Vpo/GxPnh4oSfRzEpR 6idMKxiaMWoIdGzqulpID8zbL57qFPi0L8pS/m4piWpVKAQI8GO0ue/yzQfxDFVSIK51A/cI50yRE ycD6SJ/KUWJLKcvh8nyELQ==; Original-Received: from [87.69.77.57] (port=2378 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 1oGWzZ-0008GS-QY; Tue, 26 Jul 2022 22:41:46 -0400 In-Reply-To: (message from Gregory Heytings on Tue, 26 Jul 2022 20:55:05 +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:237995 Archived-At: > Date: Tue, 26 Jul 2022 20:55:05 +0000 > From: Gregory Heytings > cc: gerd.moellmann@gmail.com, 56682@debbugs.gnu.org, monnier@iro.umontreal.ca > > My conclusion is different: we will see more such cases, but only with > truncate-lines enabled, and that means that truncate-lines should be > disabled in such buffers. I think these two issues are almost orthogonal. Even if we decide to disable truncate-lines in such buffers, we won't prevent users from enabling it. And if and when they enable it, we'd still like to give them the best performance we can. So speeding up the performance when truncate-lines is enabled is still a worthy goal, although if that is disabled in long-line buffers, that goal becomes less important. > The fundamental problem is that with truncate-lines we cannot really > narrow the buffer to a smaller (contiguous) portion without creating > problems. Yes, we need to find speedup opportunities that aren't solved by narrowing. But what I see for now is that the main bottleneck when lines are truncated is reseat_at_next_visible_line_start, because we call it each time we reach the right edge of a window, and need to decide where to display the next screen line. I've sped that up with recent commits on the branch, but it is still very slow in some situations, such as the one with isearch-lazy-highlight. Another situation which slows it down tremendously is when show-paren-mode (which is ON by default nowadays) has a highlighted parenthesis somewhere in the portion of the buffer outside of the viewport, the part that reseat_at_next_visible_line_start needs to traverse to get to the next newline. I'm trying to speed up these situations as much as possible, and I think it will serve us well even if we decide to turn off truncate-lines in long-line buffers.