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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.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 19:00:27 +0300

> Date: Thu, 04 Aug 2022 15:08:07 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: gerd.moellmann <at> gmail.com, 56682 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, 
>     dgutov <at> yandex.ru
> 
> 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.  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.

> But you're right, this slowdown has little to do with bidi.  A file with a 
> sufficiently long single line of Arabic text has the same problem.  (But 
> not one with a line of Hebrew text.)

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 I think we are good here, do you agree?

Previous Next

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