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 09:46:31 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > See above: show-trailing-whitespace is not the main culprit here;
> > these particular display properties are.  If you could produce a perf
> > profile with this recipe, it might give ideas for speeding up the C
> > code without any changes on the Lisp level.
> 
> Here are perf results when typing, using the same recipe.
> 
> Full summary:
> 
>     29.89%  emacs         emacs                       [.] lookup_char_property
>     16.58%  emacs         emacs                       [.] next_interval
>     13.99%  emacs         emacs                       [.] Fassq
>      5.44%  emacs         emacs                       [.] find_interval
>      5.17%  emacs         emacs                       [.] Fcdr
>      3.97%  emacs         emacs                       [.] 
> Fnext_single_property_change
>      2.32%  emacs         emacs                       [.] 
> composition_compute_stop_pos
>      1.51%  emacs         emacs                       [.] 
> validate_interval_range
>      1.03%  emacs         emacs                       [.] 
> get_char_property_and_overlay
>      0.99%  emacs         emacs                       [.] textget
>      0.79%  emacs         emacs                       [.] plist_get
>      0.77%  emacs         emacs                       [.] 
> produce_stretch_glyph
>      0.76%  emacs         emacs                       [.] balance_an_interval
>      0.54%  emacs         emacs                       [.] lface_hash
> 
> Call graph:
> 
> (next_interval is spread thin across the call graph, used all over the place)
> 
> 99.10%--command_loop_1
>  97.65%--read_key_sequence
>   97.55%--read_char
>    97.51%--redisplay redisplay_internal
>     97.49%--redisplay_windows internal_condition_case_1 redisplay_window_0
>      97.49%--redisplay_window
>       |65.03%--try_window
>       ||32.55%--display_line
>       || 28.90%--get_next_display_element
>       ||  28.83%--next_element_from_buffer
>       ||   28.75%--handle_stop
>       ||    23.87%--compute_stop_pos
>       ||     23.52%--composition_compute_stop_pos
>       ||      21.61%--find_composition
>       ||       21.31%--Fnext_single_property_change
>       ||        17.84%--textget
>       ||         16.84%--lookup_char_property
>       ||        6.15%--builtin_lisp_symbol
>       ||         5.28%--make_lisp_symbol
>       ||        5.94%--Fassq
>       || 32.47%--partial_line_height move_it_to
>       |   31.11%--move_it_in_display_line_to
>       |    28.95%--get_next_display_element
>       |    28.86%--next_element_from_buffer
>       |     28.80%--handle_stop
>       |      ... 16.75%--lookup_char_property
>       |32.42%--set_vertical_scroll_bar
>         32.41%--move_it_to
>        31.05%--move_it_in_display_line_to
>         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.

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.

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).