GNU bug report logs - #57207
29.0.50; Fontification is slow after e7b5912b23 (Improvements to long lines handling)

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: larsi <at> gnus.org, 57207 <at> debbugs.gnu.org, yantar92 <at> gmail.com
Subject: Re: bug#57207: 29.0.50; Fontification is slow after e7b5912b23
 (Improvements to long lines handling)
Date: Mon, 22 Aug 2022 15:32:46 +0300

> Date: Sun, 21 Aug 2022 19:38:11 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: larsi <at> gnus.org, 57207 <at> debbugs.gnu.org, yantar92 <at> gmail.com
> 
> 
> >> It is better to do that higher, because not only those places in 
> >> decode_mode_spec may wish to access BEGV and ZV.  Even in the mode-line 
> >> display there are :eval and :when.
> >
> > Okay, I'll see what I can do.
> >
> 
> Now done in the feature branch, together with a few other improvements.

Thanks.

However, resetting the narrowing in _all_ buffers at the beginning of
each redisplay cycle could be quite expensive in sessions with many
hundreds of live buffers.  E.g., my production sessions routinely have
300+ buffers, and I'm sure there are larger sessions out there.  (We
could perhaps make that less expensive by avoiding the potentially
costly calls to buf_charpos_to_bytepos, but still.)  How much time
does the loop in reset_outermost_narrowings take per live buffer?

Should we perhaps maintain a list of buffers with such narrowing?  It
should be a very short list.

Previous Next

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