bug#62780: 30.0.50; Redisplay gets slow when using Org tables + show-trailing-whitespace

[Eli Zaretskii]

> 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?