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#62780: 30.0.50; Redisplay gets slow when using Org tables + show-trailing-whitespace Date: Thu, 13 Apr 2023 17:33:09 +0300 Message-ID: <83sfd34ztm.fsf@gnu.org> References: <87mt3e8d50.fsf@localhost> <83y1my8bmi.fsf@gnu.org> <87h6tm8awi.fsf@localhost> <83bkjt8t4l.fsf@gnu.org> <87bkjsf72g.fsf@localhost> <83ttxk3vt8.fsf@gnu.org> <873554f2ye.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8884"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 62780@debbugs.gnu.org To: Ihor Radchenko Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Apr 13 16:33:54 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 1pmy1J-00026f-4Z for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 13 Apr 2023 16:33:53 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pmy0y-0000JS-0w; Thu, 13 Apr 2023 10:33:32 -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 1pmy0m-0000Db-7K for bug-gnu-emacs@gnu.org; Thu, 13 Apr 2023 10:33:21 -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 1pmy0U-0004yk-VW for bug-gnu-emacs@gnu.org; Thu, 13 Apr 2023 10:33:14 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pmy0U-0003DZ-FQ for bug-gnu-emacs@gnu.org; Thu, 13 Apr 2023 10:33: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, 13 Apr 2023 14:33:02 +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.168139635012319 (code B ref 62780); Thu, 13 Apr 2023 14:33:02 +0000 Original-Received: (at 62780) by debbugs.gnu.org; 13 Apr 2023 14:32:30 +0000 Original-Received: from localhost ([127.0.0.1]:44393 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pmxzy-0003Cb-3g for submit@debbugs.gnu.org; Thu, 13 Apr 2023 10:32:30 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:39668) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pmxzw-0003CI-Gj for 62780@debbugs.gnu.org; Thu, 13 Apr 2023 10:32:29 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pmxzq-0004pk-U6; Thu, 13 Apr 2023 10:32:22 -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=kaPXF1/Q6LGnsxleOqg7ocizU/d5eABS43Jds4GSS/k=; b=p4VkmdeyxK+B P8GTYF3AVL2qAed7Ku5ovdxnn5+lAg60CDBuPdHIibJ4o7I2o4KWPcFUfvUZWPcxQjfD6U8crTRnD SpVw353TubnOSBg3EeLPaC6FMznOCSvrhy4h/pc8D22cwaj++pVKpzaOiH/sMrg61w5s58j+wUraJ KtPAaBzlq2dY+tiEF+lfkP06ID/bBX3NZ1vIGL4OpJKCyRgQpcBikoV3bQudrTKnW14gR9yeNR2g7 /T7/CStXS/vWUK9UTy06b53dm+DioAOanvvi78Y/Qkgr9R8vkRvfizQeB16rbrwqJyUl0QOMcXruB ugaJQLBOm8IzJKH/W3RuyQ==; Original-Received: from [87.69.77.57] (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 1pmxzq-0000Zx-Ci; Thu, 13 Apr 2023 10:32:22 -0400 In-Reply-To: <873554f2ye.fsf@localhost> (message from Ihor Radchenko on Thu, 13 Apr 2023 11:15:21 +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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:259855 Archived-At: > From: Ihor Radchenko > Cc: 62780@debbugs.gnu.org > Date: Thu, 13 Apr 2023 11:15:21 +0000 > > 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. Are you sure? look up_char_property is also called for processing 'display' properties. Here's the chain: handle_display_prop -> get_char_property_and_overlay -> Fget_text_property -> textget -> lookup_char_property > 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. These ideas came up before, but implementing them is not easy and would add quite a bit of complexity. We could, perhaps, keep a buffer-local flag to record whether 'composition' property was ever set on any buffer text, but once the flag is set, we won't easily know if it could be reset. Moreover, I just disabled static compositions completely, by making find_composition return zero immediately, which basically avoids the calls to next/previous-single-property-change which search for 'composition' property, and I still see quite a significant slowdown with the recipe of this bug (50x30 org-table). Can you reproduce this? If you can, what does the profile say now?