GNU bug report logs - #62352
Very slow scroll-down-line with a lot of text properties

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: geza.herman <at> gmail.com
Cc: 62352 <at> debbugs.gnu.org, gregory <at> heytings.org
Subject: Re: bug#62352: Very slow scroll-down-line with a lot of text
 properties
Date: Sat, 25 Mar 2023 20:49:54 +0300

> Date: Sat, 25 Mar 2023 18:38:19 +0100
> Cc: gregory <at> heytings.org, 62352 <at> debbugs.gnu.org
> From: Herman, Géza <geza.herman <at> gmail.com>
> 
> > IOW, it is not as simple as you seem to think.
> I didn't meant to imply that it is easy. It is certainly not. But, tbh, 
> while emacs is fluid most of the time, it can be very stuttery 
> sometimes. In my experience, this is usually caused by some lisp code. 
> But when it isn't, it is usually caused by some code in this area. When 
> I profile emacs, these functions (next_property_change and similar) are 
> usually on the top of the list. So it would make sense to optimize 
> around this area. Not just because of this issue, but in general.
> 
> I'm not necessarily suggesting a cache. Maybe it's better to actually 
> always manage additional data structures. So, if a text property is 
> added, it's not just set for the specific character area, but it will 
> also modify search structures right away. So additional data structures 
> were always in sync. Sure, it has some overhead. But if emacs does a lot 
> of linear searches (and having a look at these functions, I see a lot of 
> linear searches), this overhead will be quickly mitigated by the much 
> faster searches. For example, if emacs had a list which only contained 
> text segments with the composition property, the current 500-char area 
> search will be much faster.

Emacs already handles text properties using an efficient data
structure, see intervals.c.  Feel free to suggest improvements to the
algorithms we use there.

Previous Next

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