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: Fri, 14 Apr 2023 09:20:01 +0000 Message-ID: <87zg7an7lq.fsf@localhost> 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> <83sfd34ztm.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="6130"; 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 Fri Apr 14 11:18:24 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 1pnFZX-0001OU-VH for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 14 Apr 2023 11:18:24 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pnFZF-0007c1-TN; Fri, 14 Apr 2023 05:18:06 -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 1pnFZD-0007aQ-Fy for bug-gnu-emacs@gnu.org; Fri, 14 Apr 2023 05:18:03 -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 1pnFZC-00049m-Sk for bug-gnu-emacs@gnu.org; Fri, 14 Apr 2023 05:18:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pnFZC-0007CH-Go for bug-gnu-emacs@gnu.org; Fri, 14 Apr 2023 05:18:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 14 Apr 2023 09:18: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.168146387727647 (code B ref 62780); Fri, 14 Apr 2023 09:18:02 +0000 Original-Received: (at 62780) by debbugs.gnu.org; 14 Apr 2023 09:17:57 +0000 Original-Received: from localhost ([127.0.0.1]:45503 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pnFYw-0007Ba-AM for submit@debbugs.gnu.org; Fri, 14 Apr 2023 05:17:57 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]:58657) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pnFYg-0007B4-Nk for 62780@debbugs.gnu.org; Fri, 14 Apr 2023 05:17:45 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id A5A59240291 for <62780@debbugs.gnu.org>; Fri, 14 Apr 2023 11:17:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1681463844; bh=HgwtyvwJHTSjvFtbH6FVfAKdxYdQOT1WBVLX6wC8hZE=; h=From:To:Cc:Subject:Date:From; b=f/XaJNhH99XETWjTciUt3nlMTnzprp9NS7UeVtUIiH4Rf6rgwG3sH1S5Li3zmj3Rr 3m68tRmH6ojaWd0s1taVpH6982mATVar220Nic/Ep1Xt33jrc89req2HOC8esM493i PB0S4gUXEoL/DfeHKNioOBShQ5r7I+us2pU2gsW8o7+KPSS53k2GPPWKBSF7uJFiII BEJSqglX7w4llFnW48+B58XxLr2J5mFKOV9cpTxCHwl5N/1c2XPmHgyqquf+aQzIUp NOVoDWus1FEZN3Wgad7SMbZLyoWsliZfuO/x6g9bzzmbc5FExzJ3DR2m5YqB1yw9Wx 4lrbd1QZ9LZwQ== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4PyW78042gz9rxP; Fri, 14 Apr 2023 11:17:23 +0200 (CEST) In-Reply-To: <83sfd34ztm.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:259898 Archived-At: Eli Zaretskii writes: >> 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 AFAIU, it does not show up in the call graph. So, even if it is called, somehow, it should be fewer times. May composition be queried excessively compared to 'display? >> 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. Is it a problem to keep multiple interval trees: one for all properties, and several for individual properties? Then, all the code dealing with intervals can be extended, repeating interval tree edits for the extra trees. When the special properties are requested, we can then work with special trees instead. > 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. I do not feel like it will improve things in practice - complex buffers with 'display/'composition properties are the ones that tend to be slow. Simpler buffers with less text properties are already not problematic. > 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? I cannot reproduce. The typing has no noticeable delays. I used ./configure && make with @@ -421,6 +421,7 @@ find_composition (ptrdiff_t pos, ptrdiff_t limit, ptrdiff_t *start, ptrdiff_t *end, Lisp_Object *prop, Lisp_Object object) { + return 0; Best, Ihor