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

Previous Next

Full log

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

From: Herman, Géza <geza.herman <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
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 22:39:34 +0100

On 3/25/23 18:49, Eli Zaretskii wrote:
>> 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.
The problem is not there. The problem is that find_composition is only 
interested in the composition property, yet it scans all the properties 
linearly. And it scans it for 500 characters. This file has a lot of 
properties, this means a lot of unnecessary and duplicated work (because 
it does this for each character displayed, or something like this). If 
the composition property had its own list, then this problem wouldn't exist.

Anyways, I commented out those lines, the problem is gone, and 
everything still seems to work. I'll report back if I find some problems 
with it.

Previous Next

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