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

Previous Next

Full log

Message #32 received at 62780 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: 62780 <at> debbugs.gnu.org
Subject: Re: bug#62780: 30.0.50; Redisplay gets slow when using Org tables +
 show-trailing-whitespace
Date: Thu, 13 Apr 2023 17:33:09 +0300

> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Cc: 62780 <at> debbugs.gnu.org
> Date: Thu, 13 Apr 2023 11:15:21 +0000
> 
> Eli Zaretskii <eliz <at> 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?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.