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

Previous Next

Full log

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

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
Subject: Re: bug#56682: Fix the long lines font locking related slowdowns
Date: Thu, 28 Jul 2022 17:16:32 +0000

>
> I think such long lines happen in files that have very little except the 
> long line.  So duplicating it makes the use case much less important.
>

That's not correct.  Some files have indeed have a single long line, but 
others have more than one long line.  Duplicating the line in that file 
was just a quick way to generate a file with more long lines.  For 
example, a database dump will typically contain one long line for each 
table.  I have a database dump here with ~100 lines that are each about 1 
MB long, each of which is a single "insert into" statement.

>
> This is actually a bug in isearch.el: using window-end in a buffer under 
> truncate-lines is simply wrong.
>

The measurements I gave were with isearch, but as I said you see the same 
kind of slowdowns with motion and insertion commands.

>
> But that's not a fundamental problem, or at least I don't yet see why it 
> would be fundamental.  It's something specific to isearch.el and to how 
> isearch-lazy-highlight is implemented.
>

No, the measurements I gave were with isearch-lazy-highlight turned OFF. 
And it is the fundamental problem, because it means that all display 
routines have to deal with a very large amount of data.

>
> I still have one or two ideas to try, and they don't involve anything as 
> complex as some new kind of narrowing.
>

Okay, so I'll wait a bit more.  I'd like to reach a conclusion as to 
whether truncate-lines should be turned off when long_line_optimizations_p 
is on before merging the branch into master.

Previous Next

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