GNU bug report logs -
#56682
Fix the long lines font locking related slowdowns
Previous Next
Full log
Message #925 received at 56682 <at> debbugs.gnu.org (full text, mbox):
>> 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 8 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.