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: Thu, 28 Jul 2022 20:44:59 +0300 Message-ID: <83k07x8738.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> <83sfmnb7yg.fsf@gnu.org> <837d3ybh5z.fsf@gnu.org> <136c4fe0fc74196714aa@heytings.org> <83pmhp89ov.fsf@gnu.org> <136c4fe0fc39573addc9@heytings.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35186"; 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 Thu Jul 28 19:46:13 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 1oH7aP-00090W-Eh for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 28 Jul 2022 19:46:13 +0200 Original-Received: from localhost ([::1]:59130 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oH7aN-0006Il-NM for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 28 Jul 2022 13:46:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53254) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oH7aE-0006I1-IF for bug-gnu-emacs@gnu.org; Thu, 28 Jul 2022 13:46:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41379) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oH7aE-0008Lr-8f for bug-gnu-emacs@gnu.org; Thu, 28 Jul 2022 13:46:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oH7aE-000553-2M for bug-gnu-emacs@gnu.org; Thu, 28 Jul 2022 13:46:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 28 Jul 2022 17:46: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.165903030419445 (code B ref 56682); Thu, 28 Jul 2022 17:46:02 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 28 Jul 2022 17:45:04 +0000 Original-Received: from localhost ([127.0.0.1]:59361 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oH7ZH-00053Z-Nc for submit@debbugs.gnu.org; Thu, 28 Jul 2022 13:45:04 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:39642) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oH7ZC-00052h-G3 for 56682@debbugs.gnu.org; Thu, 28 Jul 2022 13:45:01 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:52668) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oH7Z7-0007rP-3l; Thu, 28 Jul 2022 13:44:53 -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=ehwPZ67SIByNdSBpXg9yc2Ch0+ydJMrkUwuXVxHEnXM=; b=jVuu1WKhZSZa 7X3TKTIaHP195uxffbrpV/4XPJqivvrbSZ23Bcwbx0LP25XIVKABjfY4ZX+Ji4Xe+0hQnuilu0+We c18JUe2wHEH0/P2kZLMfvguPdwbJrr7YujZySMaIqb1kq+v8U1ZriiaAd/gU+GBeKcBtiU7SP7i0S DufY8n+OxoDCseOBZHUSJU0vKfzP/ZMsgZLf1wxKi46aQHjOjGf8R7dCpitqSqbAwwsIsGCNQn0Bp wA6NgZWHpL+pCs/lAngGuCES6Bqw/DZZFOiESoy8Vgnk9e5grVyFy4r78R4QkAySnpVavoqyVj3Zs 26NvZh29Pi78qiCJTI8MnQ==; Original-Received: from [87.69.77.57] (port=3350 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 1oH7Z3-0004Sc-PQ; Thu, 28 Jul 2022 13:44:52 -0400 In-Reply-To: <136c4fe0fc39573addc9@heytings.org> (message from Gregory Heytings on Thu, 28 Jul 2022 17:16:32 +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:238126 Archived-At: > Date: Thu, 28 Jul 2022 17:16:32 +0000 > From: Gregory Heytings > cc: gerd.moellmann@gmail.com, 56682@debbugs.gnu.org, monnier@iro.umontreal.ca > > > This is actually a bug in isearch.el: using window-end in a buffer under > > truncate-lines is simply wrong. > > The measurements I gave were with isearch, but as I said you see the same > kind of slowdowns with motion and insertion commands. No, that's not what I see. Without the thousands of Isearch overlays Emacs works much faster, almost 2 orders of magnitude faster. > No, the measurements I gave were with isearch-lazy-highlight turned OFF. > And it is the fundamental problem, because it means that all display > routines have to deal with a very large amount of data. By multiplying a very long and truncated line enough times you can always make Emacs useless. The speedups I have in mind scale linearly with the number of such lines, so eventually, with enough such lines, Emacs will always become very slow at some point, especially if the window is hscrolled very far to the right. That doesn't mean we shouldn't try speeding up the code: someone just told me that the perfect is the enemy of the good. > > I still have one or two ideas to try, and they don't involve anything as > > complex as some new kind of narrowing. > > Okay, so I'll wait a bit more. I'd like to reach a conclusion as to > whether truncate-lines should be turned off when long_line_optimizations_p > is on before merging the branch into master. That's unrelated. The branch was created for your work on font-lock, and if you are done with that, feel free to land it on master. I can continue working on master, and/or will create a feature branch if I feel it's justified. Thanks.