GNU bug report logs - #56682
Fix the long lines font locking related slowdowns

Previous Next

Package: emacs;

Reported by: Gregory Heytings <gregory <at> heytings.org>

Date: Thu, 21 Jul 2022 18:01:01 UTC

Severity: normal

Done: Gregory Heytings <gregory <at> heytings.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, 56682 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, dgutov <at> yandex.ru
Subject: bug#56682: Fix the long lines font locking related slowdowns
Date: Thu, 04 Aug 2022 16:25:28 +0000
>> For example C-p, C-n, C-v, M-v.  C-f and C-b also, but much less so.
>>
>> For example, open the file and do M-g c 70000 RET.  This took about 5 
>> seconds.  Now do C-n, this again took about 5 seconds.  With the 
>> optimizations, M-g c 70000 RET is almost immediate, and C-n there takes 
>> less than a second.
>
> I'm on the branch, so I am _after_ the optimizations.  I thought you 
> said even after that the navigation is sluggish.
>

Yes, that's what I said indeed.

>
> I see somewhat slower response than in "normal" files, but my build is 
> unoptimized, so where it takes 3 or 4 seconds, and optimized build 
> should be almost instantaneous. And that looks good enough to me, since 
> being a bit slower in such files is IMO fine.
>

It's not really "almost instantaneous", moving point can take (depending 
on factors I do not understand at the moment) something between 0.2 
seconds and 2 seconds.

>
> OK.  Text that goes through character compositions is expected to be 
> slower in redisplay, because character composition in Emacs works by 
> calling into Lisp.
>

So Arabic text goes through character compositions and Hebrew text 
doesn't, is that correct?

>
> So I think we are good here, do you agree?
>

Hmmm...  I still think it would be possible to do better.  With the above 
recipe (M-g g 70000 RET C-n), composition_compute_stop_pos is called 
627663 times and uses about 2 seconds of CPU time.  What surprises me (and 
makes me believe it's perhaps possible to do better) is that it is called 
repeatedly with the same arguments.  For example, when doing C-n it is 
called 26 times with charpos = 69980.




This bug report was last modified 2 years and 9 days ago.

Previous Next


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