GNU bug report logs -
#56682
Fix the long lines font locking related slowdowns
Previous Next
Full log
Message #1153 received at 56682 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>> They aren't, no. Of course it all depends on where you are in the
>> file, on your CPU, and so forth. For me (with locked narrowing
>> disabled, in dictionary.json, with emacs -Q) M-> takes about 3 seconds.
>
> And it's about 1.5s here.
>
So you're the lucky owner of a fast computer. And using an optimized
build. Not everyone is in that fortunate situation.
>
> Once.
>
No, not once. It happens every time you modify the buffer and move far
enough in that buffer.
>> Likewise, if I do for example C-s aan, and then repeat C-s, whenever
>> the next match is far enough in the buffer I see a delay of about 2
>> seconds.
>
> Sounds like a performance problem inside isearch. I might take a look.
>
No, isearch is entirely agnostic about font locking.
>> Another test you can do is to lean on C-v after opening the buffer,
>> you'll see that Emacs becomes very sluggish, sometimes I have to wait
>> more than 5 seconds to avance from one screenfull.
>
> First of all, these aren't the tests Eli asked for or I performed. Why
> don't you compare apples to oranges?
>
> Leaning on C-v isn't a scientific test anyway: it compares the speed of
> two processes internal to Emacs (event handling and rendering), rather
> than something objective.
>
It's yet another test meant to test Emacs' responsiveness, and it is as
"objective" as possible: does Emacs choke or does it not?
This bug report was last modified 2 years and 8 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.