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

[Ihor Radchenko <yantar92@posteo.net>]

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. 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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>