From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.bugs Subject: bug#62780: 30.0.50; Redisplay gets slow when using Org tables + show-trailing-whitespace Date: Thu, 13 Apr 2023 11:15:21 +0000 Message-ID: <873554f2ye.fsf@localhost> References: <87mt3e8d50.fsf@localhost> <83y1my8bmi.fsf@gnu.org> <87h6tm8awi.fsf@localhost> <83bkjt8t4l.fsf@gnu.org> <87bkjsf72g.fsf@localhost> <83ttxk3vt8.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13552"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 62780@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Apr 13 13:14:22 2023 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 1pmuuD-0003Jp-TH for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 13 Apr 2023 13:14:21 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pmutw-0002DG-Ag; Thu, 13 Apr 2023 07:14:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pmutu-0002D5-MM for bug-gnu-emacs@gnu.org; Thu, 13 Apr 2023 07:14:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pmutu-00044Q-DP for bug-gnu-emacs@gnu.org; Thu, 13 Apr 2023 07:14:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pmutt-0002qn-SF for bug-gnu-emacs@gnu.org; Thu, 13 Apr 2023 07:14:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 13 Apr 2023 11:14:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62780 X-GNU-PR-Package: emacs Original-Received: via spool by 62780-submit@debbugs.gnu.org id=B62780.168138438210876 (code B ref 62780); Thu, 13 Apr 2023 11:14:01 +0000 Original-Received: (at 62780) by debbugs.gnu.org; 13 Apr 2023 11:13:02 +0000 Original-Received: from localhost ([127.0.0.1]:42702 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pmusv-0002pC-SV for submit@debbugs.gnu.org; Thu, 13 Apr 2023 07:13:02 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]:59295) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pmuss-0002oo-9J for 62780@debbugs.gnu.org; Thu, 13 Apr 2023 07:13:00 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 5EDED240461 for <62780@debbugs.gnu.org>; Thu, 13 Apr 2023 13:12:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1681384372; bh=Aa1ks4pUN/bllbNQvTmT1H/GCqfjSRhq0bjsXv5I108=; h=From:To:Cc:Subject:Date:From; b=YtSmfW1t9RtdmwAB42/4esUceme7hLfeiGeOMibJ8Q+q44reVnce5y6jb5flbx3YU 5yjRn+Ah4gaUb6vkulxg+Sml26KO5pyLaZRJ0gteJBoKjETD1WX9VShVw6FaVhaxPa cFPcQzyKGWCYt46f3dW6S9TRi6Rd3G7kHS8eGNj930i9aURLLe5UbTd6NwRhyX/SHy bcH5iRLBnixEwXtHFbM+XiQjOPNF1rcmw5updtCMEeMLnbnjfm4nNvMw9CvaMtzzlq jNhZ9+8M+AdKWRbhJLskXOny/0UBH1qCHBdGh5cnfekmJaedLUNa9bwkitJ74ZgEPC GDwhO8vhDbJoA== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Pxxkq5jkDz9rxB; Thu, 13 Apr 2023 13:12:51 +0200 (CEST) In-Reply-To: <83ttxk3vt8.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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:259849 Archived-At: Eli Zaretskii writes: >> 28.86%--get_next_display_element >> ... 16.54%--lookup_char_property > > This unfortunately says that looking up text properties is what takes > a large fraction of the time, which is consistent with the fact that > there are a lot of text properties in the buffer, and they happen > almost every character. This looks up a very specific text property - 'composition. The property that does not even exist in the buffer. The lookup takes so long because buffer interval tree is very fragmented - each table cell adds at least 4 intervals. May Emacs hold a property cache and make textget search EQ property lists just once? Or, may it make sense to maintain additional interval trees for some important text properties like 'invisible/'composition/'display? These trees will only track text regions containing these important text properties? Then, `next-single-property-change' can be much, much faster compared to the current scan across all the buffer intervals. > So maybe the immediate band-aid would be to offer a user option, by > default off, which will control whether these 'display' properties are > used: only users who actually need to type bidirectional text inside > the table will need to turn on the option. While it might fix the immediate issue for some set of users, it will also limit our options to make use of 'display text property in tables. In particular, it will be nice to auto-adjust the table column width with pixel precision - one of the top-requested features for Org. > Another possibility is to use "Method 1" I described in > > https://lists.gnu.org/archive/html/emacs-orgmode/2017-12/msg00526.html > > I know I said afterwards that Method 2 was better (and it is), but I > obviously didn't consider the effect on performance, and neither had a > test case for that back then. So maybe Method 1, while theoretically > less desirable, will in practice do the job and avoid the performance > issues, assuming that the invisibility aspect can be ignored > (i.e. users won't mind having 1-pixel thin spaces in the cells). I'd very much prefer to avoid Method 1. It will "litter" the Org files, unless we also remove these symbols during save. And people will definitely complain about kill containing "weird" staff. So, then also substring filters. I am afraid that Method 1 will cause more trouble in practice. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at