From: Eli Zaretskii <eliz@gnu.org>
To: Ihor Radchenko <yantar92@posteo.net>
Cc: 62780@debbugs.gnu.org
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 [thread overview]
Message-ID: <83sfd34ztm.fsf@gnu.org> (raw)
In-Reply-To: <873554f2ye.fsf@localhost> (message from Ihor Radchenko on Thu, 13 Apr 2023 11:15:21 +0000)
> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: 62780@debbugs.gnu.org
> Date: Thu, 13 Apr 2023 11:15:21 +0000
>
> Eli Zaretskii <eliz@gnu.org> 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?
next prev parent reply other threads:[~2023-04-13 14:33 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-11 18:52 bug#62780: 30.0.50; Redisplay gets slow when using Org tables + show-trailing-whitespace Ihor Radchenko
2023-04-11 19:25 ` Eli Zaretskii
2023-04-11 19:41 ` Ihor Radchenko
2023-04-12 7:19 ` Eli Zaretskii
2023-04-12 7:39 ` Ihor Radchenko
2023-04-12 7:58 ` Eli Zaretskii
2023-04-13 9:46 ` Ihor Radchenko
2023-04-13 10:45 ` Eli Zaretskii
2023-04-13 11:15 ` Ihor Radchenko
2023-04-13 14:33 ` Eli Zaretskii [this message]
2023-04-14 9:20 ` Ihor Radchenko
2023-04-14 10:37 ` Eli Zaretskii
2023-04-14 11:36 ` Ihor Radchenko
2023-04-14 12:06 ` Eli Zaretskii
2023-04-14 12:23 ` Eli Zaretskii
2023-04-14 12:52 ` Ihor Radchenko
2023-04-14 13:51 ` Eli Zaretskii
2023-04-14 13:56 ` Ihor Radchenko
2023-04-14 14:47 ` Eli Zaretskii
2023-04-14 14:56 ` Ihor Radchenko
2023-04-14 15:06 ` Eli Zaretskii
2023-04-14 15:23 ` Ihor Radchenko
2023-04-14 12:28 ` Ihor Radchenko
2023-04-29 8:57 ` Eli Zaretskii
2023-04-29 18:03 ` Ihor Radchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83sfd34ztm.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=62780@debbugs.gnu.org \
--cc=yantar92@posteo.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).