[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Low redisplay performance (23 regression)
From: |
Stefan Monnier |
Subject: |
Re: Low redisplay performance (23 regression) |
Date: |
Wed, 29 Apr 2009 16:20:49 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux) |
>> > As I use `end-of-defun' in my customized
>> > `font-lock-extend-region-functions' this does have an impact on the
>> > overall performance of fontification for me on large files.
>> I don't think the size of the file (aka buffer) should make
>> a difference.
> Yes, I meant to write on large defuns. I test this on a file which
> contains defuns spanning up to 500-600 lines.
Yes, that makes sense.
> I'm not sure how much you can do with this information. But I can concur
> with the OP that there does seem to be a performance regression.
Indeed font-lock-fontify-keywords-region (which is the part which I'd
expect to take the bulk of the time and would be a source of performance
problems no matter how you implement your
font-lock-extend-region-functions if you force refontification of the
whole defun every time), so as I was saying
font-lock-fontify-keywords-region got about twice as slow. And I can't
explain it. As far as I know, this part of font-lock has not been
changed in any significant way. What happens if you use Emacs-22's
font-lock.el in Emacs-23?
> > So it's about twice as slow for this test, which is the expected in this
> > case: since your benchmark always calls it with point between 2 defuns,
> > it ends up doing: BOD-raw to find the previous defun, EOD-function to
> > find its end, which tells Emacs that the starting point was after the
> > previous defun, so it calls BOD-raw again to find the next defun and
> > finally EOD-function to get to its end.
> Why didn't 22.x do this? Probably to fix some bug, right?
No, you're right. Emacs-22's code is very different, but it should end
up doing pretty much the same thing (two calls to BOD-raw plus two calls
to forward-list) and I see no reason why it should be any faster.
Stefan
Re: Low redisplay performance (23 regression), Tassilo Horn, 2009/04/29
Re: Low redisplay performance (23 regression), Chong Yidong, 2009/04/29